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
>
>
>   

Reply via email to