more good news -
The bundle plugin was reporting 2 warnings - one was the one noted below, and
another was when the <Bundle-Exports> instruction was left off of the individual
component pom. In this last case, it is supposed to "default" - by looking in
the project's src/java (I think) and finding the "packages" other than ones with
"impl" in them - see the bundle docs, where it says:
<Export-Package> is now assumed to be the set of packages in your local Java
sources, excluding the default package '.' and any packages containing 'impl' or
'internal'.
/(before version 2 of the bundleplugin it was based on the symbolic name)/
I tried upgrading from our default version 2.1.0 to the latest 2.3.5, and it
made all these problems go away :-)
-Marshall
On 7/27/2011 5:23 PM, Marshall Schor wrote:
> 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
>>>
>>>
