An update, after spending some time on this.
There are 4 kinds of builds:
1) single-project build
2) PEARs
3) OSGi
4) The aggregation of all the addons into one binary zip/tar
The PEAR build uses the PearPackaginMavenPlugin which does a lot of local
copying from the source tree, presumed to be layed out in standard PEAR format,
and a special, hard-coded subdirectory of target, called pearPackaging.
So - it's going to populate this anyways from the source tree.
The OSGi maven bundle plugin I can't make work unless I have it jar up things in
the standard place, and place the lib/ for dependencies in the target/classes
directory.
So the commonality I was hoping for seems hard to get. I can get some from
sharing the build for (1) and (4), though.
-Marshall (making slow progress)
On 7/26/2011 4:48 PM, Marshall Schor wrote:
> Now that I've prototyped the osgi build (not yet checked in), and revisited
> the
> other binary builds, it seems there's a lot of similarity among these.
>
> I think there are 3 kinds:
>
> 1) single-project build - like FsVariables, and SimpleServer
> 2) PEARs
> 3) OSGi
>
> The single-project and PEARs seem almost identical, except the PEARs have a
> special install.xml file (for installing the PEAR). (One superficial
> difference
> is that the docs directory in PEARs is "doc", and in single-projects, is
> 'docs').
>
> They both include documentation in "built" form (PDFs and HTML files), and
> javadocs.
>
> The OSGi form has a special MANIFEST.MF file, and doesn't include
> documentation
> or javadocs.
>
> The zip/tar-ing of these is somewhat different: single-project has a zip/tar
> assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR (which is
> of
> course, a zip). In addition, the addons "aggregate" of all the addon projects
> has all of them zipped/tarred up together.
>
> There is also for most things, a standard JAR packaging of just the core
> annotator, containing class/ directory.
>
> The OSGi build as far as I can tell *requires* (by which I mean that I
> couldn't
> figure out how to override this) that the main set of classes be in the
> standard
> ${project.build.outputDirectory}. In contrast, the PEAR and single-project
> build are packaging the main set of classes by letting the standard JAR plugin
> package them as a jar, and then including that JAR in the lib/ of the
> zip/tar.
> So the lib/ of those packagings is slightly different from the lib/ of the
> OSGi
> packaging - in that the OSGi doesn't have the main set of classes as a
> separate
> inside its lib/ directory.
>
> The build logic for these eventually should be in the build/ part, in the
> overall parent-pom, and in the related uima-build-resources project. But for
> now we are having addons-level overrides for this in the uima-addons-parent
> pom,
> and for uima-addons aggregate assembly, in the src/main/assembly directory.
>
> It seems that a small bit of restructuring would help in the overall building
> of
> things. This would have a common part of these build steps do the collection
> of
> all the parts that are destined to go into the zip/tar etc.
>
> The single-project build and the PEAR have the most in common, the OSGi the
> least.
>
> I'm currently thinking that all addons should include a single-project build
> (zip/tar).
> Those marked as PEARs should also have a PEAR build.
> Those marked as OSGi should also have an OSGi build.
>
> The binary addons aggregate I think should drop the individual single-project
> zip/tar - there's little value to having this done 2x.
>
> For uploading to Maven repository: the main Jar is uploaded, the
> source-release
> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
> zips, too. So the only thing not uploaded would be the single-project zip/tar.
>
> Does this seem right to others?
>
> I'll work on refactoring the addons build to take advantage of all this
> commonality :-)
>
> -Marshall
>
>
