uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: Possible new binary packaging approach for Annotator Add-ons
Date Mon, 10 May 2010 07:47:02 GMT
I am +1 for separating individual add-ons and if I understand correctly
using maven-assembly plugin for non-PEAR stuff with a different
configuration would be the best solution.
Tommaso

2010/5/10 Marshall Schor <msa@schor.com>

> Not all projects in the Add-ons release are annotators.  Those other
> projects, if they were to also be released as "single project" releases,
> would need to have individual binary assemblies.
>
> I took a crack at doing such a binary assembly, it looks like:
>  - lib: has the jar artifact (if there is one) plus all dependent jars
> with scope that includes runtime (i.e. compile and runtime)
>  - bin: populated from src/asm/bin if there's something there, with
> execute permissions set on for .sh
>  - everything copied from src/asm (excluding bin - already copied) - to
> allow things that are not packaged with the main artifact (usually a
> Jar), but which should be included in the binary distribution.
>  - docs - output from docbook - the pdf and html versions
>  - files from the project's top level - copied into the binary
> distribution's top level: the Lic/Notice/Readme/RelNotes files
>
> This work is done by a parent-pom, uniformly, if a project lists that
> parent-pom as its parent.  This would be an alternative to PEAR
> packaging, which does a similar thing, but uses the PEAR system.
>
> I'm hoping these two kinds of binary packagings will be sufficient for
> our sandbox projects.  Next step is to finish converting the rest of
> them and see if any new requirements pop out.
>
> -Marshall
>
>
>
> On 5/7/2010 12:54 PM, Marshall Schor wrote:
> > In our 2.3.0 release, the addons package (which has annotators plus some
> > other stuff) did a binary packaging for the annotators twice:
> >
> >   - Once as a Pear (at least for most of the Annotators), and
> >   - once as part of the big binary assembly that became the add-on
> > binary package.
> >
> > I think it would be better to avoid this duplication, and use only the
> > Pear as the binary form for each annotator component, and have them as
> > individual downloads.
> >
> > This way, if someone wanted, say, the Dictionary Annotator, they could
> > just get it (even from Maven - as I plan to attach the PEARs as
> > artifacts) by itself, without needing to download lots of other binary
> > stuff (like the Tagger project, which has giant data resources...).
> >
> > If we made this change, one new requirement would be that annotators
> > would have to use pear packaging if binary distribution was wanted; one
> > annotator that would need this change, for instance, is the BSFAnnotator.
> >
> > Another advantage if we did this would be we could only release
> > Annotators which change (when we do major releases), leaving the others
> > alone; this would reduce the "rate of change" that impose on our user
> > community, which is a good thing I think, and seems more in alignment
> > with the Maven way of change management of components with dependencies.
> >
> > Anyone else think this is a good idea? Any objections?
> >
> > -Marshall
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message