Note: topic is unrelated to AEM and based on another Adobe technology, LiveCycle.
Adobe provides much documentation on LiveCycle ES4 component creation. Unfortunately, that documentation is a site-copy from the ES2.5 instructions and, as of the time of this post’s publication, has not been updated to account for ES4 changes. Therefore, much of it is obsolete and many links and downloads are no longer functional. In this post, I’ll try to bridge the gap between the outdated documentation and the necessary changes required to create and deploy custom components on ES4.
Adobe seems to no longer publish a LiveCycle component development plugin for Eclipse. Even finding the ES2.5 version of the plugin is difficult. Installing it is harder, since many of the libraries and dependencies are missing or had version changes. My steps included finding old versions of these files on coworker’s hard drives and manually modifying the jars and their metadata before repackaging. Describing the process is painful, so here’s the full Eclipse instance of the LiveCycle ES2.5 Component Developer plugin:
- http://aem.matelli.org/wp-content/uploads/2014/06/eclipse-es4.7z (329MB) Windows x64
And if you’re just interested in just the plugin itself, which Adobe’s documentation inexplicably refers to as adobe-tools.zip and incorrectly claims it’s located within the LiveCycle workbench install directly (it’s absent from 3.5 or 4.0), here’s that file:
You may have more luck with my modified version, which works around a dependency error caused by some changes in the beta version of Eclipse that their plugin used. The error reads: Cannot complete the install because one or more required items could not be found. With details of the missing constraint pointing to: ‘bundle org.junit188.8.131.52’.
Fixing it requires diving into the jar, opening another jar inside that, then tweaking its MANIFEST.MF to swap org.junit4 references with org.junit. Or you can try the version I already modified in this manner.
Some other finagling was required, so if you test this, please add a comment to this post with the results. In the interest of saving time, I recommend anyone using Windows to just use the full eclipse zip file linked above.
Building a Project:
Because the Eclipse plugin is for ES2.5, some changes need to be made to support ES4 deployment. The ANT build script does work out of the box, but requires tweaks to be compatible with ES4. First, make sure it’s building with JDK 1.6 and not 1.7. Otherwise installing, patching, or starting the the component might yield some nondescript errors:
- Invalid jar file
- patch of component com.foo.Component failed
- RuntimeException in method: public abstract java.lang.Object com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionBMTAdapterLocal.doBMT(com.adobe.idp.dsc.transaction.TransactionCallback) throws com.adobe.idp.dsc.DSCException:
ALC-DSC-099-000: com.adobe.idp.dsc.DSCRuntimeException: java.lang.NullPointerException
Here’s where to check and change that version:
Classpath Considerations :
When creating a new Adobe LiveCycle component project, the “Add jars to this project” checkbox enabled us to include required jars. They then are included in the classpath and packaged along with the component. Note that if you’re upgrading from a previous version a component, a few third-party jars have changed. Two tips to deal with these:
- Be sure everything enumerated in the component.xml file <class-path> property is valid and still exists.
- Any jars that need to be included in your component jar should be copied at root level (as described here).
The needed files can be enumerated in the build.xml file explicitly, then copied to the jar and exported to the component.xml classpath. Here’s an example of some snippets you can add to preform the former.
If you don’t include these classpath-referenced library jars in the component jar, here’s an example server log you’ll see:
WARN [com.adobe.idp.dsc.management.impl.ComponentClassLoaderSource] (http-184.108.40.206-8080-1) Jar file: log4j.jar does not exist in component: com.mycomponent.Foo.1.0
An error loading them because of this will look something like the following:
ERROR [com.adobe.workflow.AWS] (WorkManager(2)-28) An exception was thrown with name java.lang.NoClassDefFoundError message:org/apache/commons/discovery/tools/DiscoverSingleton while invoking service FooService and operation fooOperation and no fault routes were found to be configured. ... WARN [com.adobe.workflow.AWS] (WorkManager(2)-28) java.lang.NoClassDefFoundError: org/apache/commons/discovery/tools/DiscoverSingleton ... Caused by: java.lang.ClassNotFoundException: WorkManager(2)-28Class name org.apache.commons.discovery.tools.DiscoverSingleton from package org.apache.commons.discovery.tools not found. ... ERROR [com.adobe.workflow.AWS] (WorkManager(2)-28) An exception was thrown with name java.lang.NoClassDefFoundError message:org/apache/commons/discovery/tools/DiscoverSingleton while invoking service /FOO/1.0/FooBar.process(asset path: FooBar.process) and operation invoke and no fault routes were found to be configured.
When this happens, make sure the referenced jars are included in the component jar. The above error in particular is referring to the missing commons-discovery.jar library. This wasn’t explicitly included in previous versions. Another jar to note when upgrading components from earlier versions is jaxen-1.1.1.jar, which was changed from jaxen-1.1-beta-9.jar.
With these changes and considerations, Adobe’s official documentation should provide the rest needed for custom component creation. If I missed anything, please be sure to leave a comment.