With the acquisition of Day, there has been a lot of work within engineering to integrate CRX into the LiveCycle ES technology stack. However, since LiveCycle ES is an extensible platform – as I have been preaching for the last few years 🙂 – there is no need to wait until the next version of the product is available to take advantage of CQ and CRX.
To demonstrate this point, I have build a custom component (DSC) for LiveCycle ES that uses the JCR api. Of course, I used the Component Development Tool posted on labs.adobe.com to create this component.
I built this component with service configuration parameters that enable you to define the CRX server URI and account information. Since this is just a sample, I took a shortcut and enabled hardcoded credentials to connect to CRX. The service has two operations addContent and retrieveContent. The operation properties are very straight forward. All you need to do is specify the CRX path where to save or retrieve the content, file name, etc.
Custom Component Eclipse Project (compiled JAR in the dist folder)
This does not replace the great work that will be coming out in the next release of LiveCycle ES. If you have not registered for the LiveCycle ES prerelease program, you need to check it out. This is a closed beta. to enroll, contact your Adobe sales rep.
After posting the previous article about being able to merge LCA files, another colleague contacted to say “This is great – but we need to generate LCA files from source as part of our build process”. It’s never enough is it? 🙂 Since most of the work was done I figured, why not add this functionality. I learned some interesting things along the way too.
I created a new class (com.adobe.tm.ant.tasks.GenerateAppInfoFile) that extends the Ant MatchingTask. My goal for this task is scan the src folder specified in the build.xml and process any LiveCycle ES applications it finds. Yes, you can create LCAs in batch! The rule is that you create a folder in src for each LC ES application you want to package. each folder MUST follow typical LCA structure. My Ant task will process each folder as a separate application and generate one LCA file per LiveCycle ES app.
Now that I have a little more experience with writing Ant tasks, I realize that it’s better practice to simply have a ant task property that points to the src folder and include the folder processing logic in the Java code [versus my approach in the previous post where I left file processing up to the build.xml author]. You will notice the simplicity in build.xml task definition. However, I feel that it’s up to the build.xml author to choose to support batch LCA file generation. For that reason, I have left the ant-contrib loop.
Here is an interesting tidbit… In the app.info file, each top-level-object (application asset) node contains a child element called properties. When I first had a look at some sample LCA files, I noticed that this node was different than the others. It’s value is clearly a Base64 encoded string. When I decoded the string, imagine my surprise when I realized that the value that was encoded is actually a serialized java.util.Properties object. After doing some investigations with my contacts in engineering, I found out that this was an element that was originally planned to contain LiveCycle ES asset configuration information, but in the end never gets used. It was planned to remove this element in the 2.5 release, but fell off the priority list. The bottom line is that although the properties element must be present with a Base64 encoded serialized java.util.Properies object – even if it’s empty. The reason is that the LCA importer looks for this entry, even if it’s not used, to validate the app.info file. I explain this, because if you look at the Java source code you’ll wonder what I am doing :o).
Binary Distribution: CustomAntTask.0.4_dist.zip
Project Source: CustomAntTask.0.4_src.zip
A couple of colleagues needed a solution where they could take multiple unrelated LiveCycle ES applications already exported as LCA (LiveCycle Archive) files and programmatically merge them into a single LCA file. What’s the use case? Let’s say that you have a source repository of small LiveCycle ES applications that are re-usable. Then, based on a set of requirements, you need to build a new LiveCycle ES application that would include those re-usable smaller apps. Of course, you could just import each application individually into your LiveCycle ES development environment. But that’s not real exciting is it? And what is more exciting than building an Apache Ant build script to do some magic?
I created a build.xml file that will grab all LCA files stored in a src folder(see the build.properties file for configuration) and extract them into a work folder. This is pretty trivial since LCA files are just ZIP files that contain the application assets as well as a file called app.info. This app.info file is the key. It’s an XML file that describes the LiveCycle ES application and what operations should be executed when imported into a LiveCycle ES server. Here comes the tricky part…
To create a “merged” LCA file, I needed to parse each app.info file of the source LCA files, build a new master and inject the individual application descriptors from the source LCA files. Can you imagine my surprise when I realized that there was no existing Ant task that does this?!?! Yeah, right! OK, so I have to create a custom Ant task – great! Turns out, yet another trivial job. It was very easy to create my own custom Ant task and expose it in the build.xml. As a reference, I used this short tutorial. All I had to do at that point is write the Java code to load each app.info file into an XML DOM, extract the necessary nodes, build a new master app.info and import the previously extracted nodes. Piece of cake ;o).
Once I included my new custom Ant task into my build.xml, I just passed in the fileset reference that contained all of the app.info files and voila… I got my first merged app.info file. We just then drop that bad boy into the build folder, copy the asset folders that came with each LCA file in there too; and with one final zip ant task package up the combined LCA file.
Note: I also used the ant-contrib package because I needed a for loop in my build.xml in order to loop through each LCA file.
You must have Apache Ant installed and configured on your machine.
Binary Distribution – Includes build.properties, build.xml, lib folder.
Source – Includes the Java source files for the custom Ant task.