You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Tommaso Teofili <to...@gmail.com> on 2011/08/01 16:05:46 UTC
Re: addons build progress
2011/7/31 Marshall Schor <ms...@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?
>
> --------------
>
> 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.
Tommaso
Re: addons build progress
Posted by Tommaso Teofili <to...@gmail.com>.
2011/8/1 Marshall Schor <ms...@schor.com>
>
>
> On 8/1/2011 10:05 AM, Tommaso Teofili wrote:
> > 2011/7/31 Marshall Schor <ms...@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
> >
>
Re: addons build progress
Posted by Marshall Schor <ms...@schor.com>.
On 8/1/2011 10:05 AM, Tommaso Teofili wrote:
> 2011/7/31 Marshall Schor <ms...@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?
>
>
>
>> --------------
>>
>> 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 :-) .
-Marshall
> Tommaso
>