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: addons build progress
Date Mon, 01 Aug 2011 14:33:03 GMT
2011/8/1 Marshall Schor <msa@schor.com>

>
>
> On 8/1/2011 10:05 AM, Tommaso Teofili wrote:
> > 2011/7/31 Marshall Schor <msa@schor.com>
> >
> >> The addons build is now operating along the following lines:
> >>
> >> Each addon is built as if it were a single project.  A common
> >> target/base-bin is
> >> created which has the main artifact plus dependencies, documentation
> >> (including
> >> javadocs) and LICENSE/NOTICE etc. for that project's binary
> distribution.
> >>
> >> This is zipped / tarred up to produce "single assemblies".
> >>
> >> This is zipped / tarred up as part of the aggregate addons big assembly.
> >>
> >> This is also used as the base for making the PEAR file (for the
> "annotator"
> >> projects only) - this adds the PEAR installation xml file, and zips up
> as a
> >> PEAR.
> >>
> >> This is also used as the base for making the OSGi file (for the
> "annotator"
> >> projects only) - this adds the OSGi manifest, and deletes things like
> >> documentation, which are not normally included in OSGi builds.
> >>
> >> ---------------
> >>
> >> The previous addons build did not create individual zips/tars of the
> >> individual
> >> projects - only the big aggregate ones.  Also, the current process is
> only
> >> producing source-release builds at the top level.  So, I think I will
> >> change the
> >> build to only produce individual zips/tars of individual projects if you
> >> run
> >> maven on the individual projects with -Papache-release.  This will make
> it
> >> consistent with how it was before, and also make the source-release.zips
> >> get
> >> generated with the binary release.
> >>
> >> We also will need to decide on the distribution channels for the
> >> individually
> >> packaged addons, if and when we release them individually.  The current
> >> Apache
> >> practice is to have the source and binary distributions for these come
> from
> >> the
> >> Apache mirror system.  An alternative is to attach these as artifacts to
> >> the
> >> main artifact and include them in the Maven deploy to Maven Central.
>  (or
> >> both).
> >
> > +1 for both
> >
> >
> >>  Currently, we "block" the maven distribution of these artifacts, and
> >> only distribute via the Apache mirror system.
> >>
> > one more thing I think it'd be nice is to have different packagings of
> each
> > addon on Maven Central so that one could include :
> >
> > <dependency>
> >  <groupId>org.apache.uima</groupId>
> >  <artifactId>BSFAnnotator</artifactId>
> >  <version>2.3.1</version>
> >  <type>jar</version>
> > </dependency>
> >
> > or
> >
> > <dependency>
> >  <groupId>org.apache.uima</groupId>
> >  <artifactId>BSFAnnotator</artifactId>
> >  <version>2.3.1</version>
> >  <type>bundle</version>
> > </dependency>
> >
> > depending on its specific needs.
> > What do you think?
>
> Good idea, but I think needs a small modification.  The "Type" of the OSGi
> build
> is also a Jar.  Maven provides another element that is for this case of
> distinguishing two different kinds of builds, the "<classifier>".
>
> I think a classifier of "osgi" would be best ("Bundle" seems a little too
> generic for me).
>
> So the alternative for the 2nd would look like:
>
> <dependency>
>  <groupId>org.apache.uima</groupId>
>  <artifactId>BSFAnnotator</artifactId>
>  <version>2.3.1</version>
>  <classifier>osgi</classifier>
> </dependency>
>
> What do you think?
>

+1 !
 :-)


>
> >
> >
> >
> >> --------------
> >>
> >> So a bit more work to do - where we keep the structure for producing
> >> individual
> >> project source/bin zips/tars so we can easily enable it going forward,
> but
> >> block
> >> the generation of these when doing the aggregate distribution.
> >>
> >> And, I have yet to verify that the aggregate binary-version
> license/notice
> >> files
> >> are the concatenation of all the included projects' license/notice files
> >> (with
> >> duplicates removed).
> >>
> >> Also, I think the OSGi build, as it is currently used, will need to
> include
> >> some
> >> UIMA SDK jars?
> >>
> > At the moment I'm not sure which is the right choice here so I've not a
> > strong opinion, only I think we should go the 'safer' way, that I think
> is
> > including such jars.
>
> +1.
>
> Thanks for voicing your views :-) .
>

:-)

Tommaso


>
> -Marshall
>
> > Tommaso
> >
>

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