some better progress - I was able to get the maven bundle plugin to build the
osgi manifest, and then jar everything up from a copy of the base binary build
spot I used for (1) and (4). So I have "sharing" of things among 1, 3, and 4.
And I'll fix the PEAR build to share too, for some of this
The maven bundle plugin, when run with the manifest goal, seems to:
1) use the bundle classpath, which includes the target/classes dir, plus the
dependency artifact jars, to do its work.
2) It "checks" this against what is specified for its Bundle-ClassPath, which I
have now set to:
<Bundle-ClassPath>.,lib/${project.build.finalName}.jar,{maven-dependencies}</Bundle-ClassPath>
where {maven-dependencies} is a bundle plugin thing set from combining the
setting of Embed-Directory (set to "lib") and the pom's dependencies. This
results in the classpath coming out in the manifest to be:
.,lib/uimaj-an-bsf.jar,lib/log4j-1.2.14.jar,lib/bsf-2.4.0.jar,lib/commons-logging-api-1.1.jar,lib/js-1.7R2.jar,lib/bsh-2.
0b4.jar
which is how the following maven jar plugin step will construct things.
The bundle plugin does check, however, if this lib/xxx structure currently
exists under target/classes - which of course it doesn't. So it issues some
warnings. But nevertheless, it creates the proper manifest and stores it in the
right place for the next Jar step to work.
So I think OSGi builds may be working :-) Now to fix the PEAR build (to share
the same common build. Then, I'll try it on all the other addons and if that
all works, I'll check in the changes... (maybe tomorrow).
-Marshall
On 7/27/2011 3:40 PM, Marshall Schor wrote:
> 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
>>
>>
