You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2011/07/31 00:36:59 UTC
addons build progress
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). Currently, we "block" the maven distribution of these artifacts, and
only distribute via the Apache mirror system.
--------------
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?
-Marshall
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
>
Re: addons build progress
Posted by Tommaso Teofili <to...@gmail.com>.
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