On 8/3/2011 6:35 PM, Greg Holmberg wrote: > > 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. You're welcome :-)
> 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. Probably a good point - to use PEAR as the "classifier". > > 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. It's not very hard to do :-) . I assume you're talking about the part of the PEAR install work that plugs in the install directory in place of $main_root etc. Some PEARs use this to support legacy code (think of "C" or C++ code) that needs absolute file system references to parts of the packaged items, such as a configuration parameter setting. > > > 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. > Looking recently into OSGi, I see there's now 2 "camps": the OSGi one, and the "Jigsaw" one. (Google Java Jigsaw). Jigsaw is the "modularization" enhancement to Java, originally for Java 7 but now for Java 8. It has some connections with Maven / Ivy approach to repositories and versioning. You can get a good overview of what's happening in this space by googling OSGi Jigsaw. -Marshall > > 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 > >
