Hi Marshall--
Thanks for your efforts on getting the add-ons built as PEARs and OSGi bundles. I will definitely use that. I would like to consume them from Nexus as maven dependencies. I am working on consuming PEAR files. I'm not there yet. What I've done so far is to create the PEAR archives using the maven assembly plug-in , deploy the files to a Nexus repository, and create a dependencies on them. In the case of a PEAR file containing a primitive annotator, I create the install.xml by hand (not using the PEAR packager). The PEAR structure is created under "src/main/resources" so that maven automatically copies it to the "target" dir. Then I just zip it up using the standard maven assembly plugin. It gets deployed to Nexus as format=zip, classifier=pear. I'm not completely happy with that, since the file extension is then ".zip", and not ".pear". I'll try to fix that later. For consuming PEARs, i n one case, a project that wants to build a PEAR containing an aggregate engine declares dependencies (type=zip, classifier=pear) on PEARs containing primitive annotators. And again, I use the assembly plug-in to include *:zip:pear and unpack them . M aven will then download the primitive-containing PEARs, unpack them , and include them in a new PEAR assembly . (I'm not using the PEAR merger tool.) That gets deployed to Nexus the same as above. In another case of consuming PEARs , an application declares a dependency on that aggregate-engine-containing PEAR, and configures the maven-dependency-plugin to unpack the PEAR in the target dir . I'm not using the PEAR installer. Maven also downloads any jar files the PEAR depends on, and configures Eclipse classpath with all the necessary elements. That's all at build time, for testing or running in Eclipse. To deploy the aggregate-engine PEAR to my UIMA service, I'm planning to let the application submit a reference to the aggregate-engine-containing PEAR as a URL (to the Nexus server). My UIMA service will download the PEAR from Nexus, unpack it, and instantiate the engine. Again, not using the PEAR installer. I haven't implemented this yet. I'm hoping to not have any need to re-write strings in any XML files (install.xml, etc.) as the PEAR installer and merger tools do. This may be wishful thinking, we'll see. In my UIMA service, for jars that the engine depends on, I will either have to include them all in the top-level PEAR, or get my service to follow the dependency chain and download them separate from Nexus. I'll probably start with the first, and implement the second later. In the near future, I would like to get this same effect but using OSGi bundles. Like the PEAR files, they will have to be unpacked, so that the annotators can read the included resource files and DLLs (in some cases) directly in the file system. As I said, it's not all working yet, and I could still hit a brick wall. I can send pom.xml and assembly.xml files if you're interested. Greg Holmberg
