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