On 8/1/2011 10:05 AM, Tommaso Teofili wrote:
> 2011/7/31 Marshall Schor <[email protected]>
>
>> 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
>
