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