Nice news Marshall!!
Let me know if you need any help :)
Tommaso
2011/7/28 Marshall Schor <[email protected]>
> 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
> >>>
> >>>
>
