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/06/16 11:25:33 UTC
uima-addons source release configuration
Hi all,
I'm working on creating a new assembly descriptor for the source release
with the proposed idea of using two separate modulesets, one for
aggregate-addons and one for addons-osgi-runtime.
However so far I didn't manage to find a proper assembly configuration to
make sure the source release package look like the SVN tag and can be built
once unzipped.
Explicitly declaring one fileset per module with proper outputDirectory will
work for sure but I wonder if you can help me find a smarter way.
Thanks in advance,
Tommaso
Re: uima-addons source release configuration
Posted by Tommaso Teofili <to...@gmail.com>.
Yes, I created a src.xml assembly descriptor in
uima-addons/src/main/assembly then added this piece to uima-addons POM so
that I can also see differences between default assembly result and the one
generated with src.xml:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>source-release-assembly</id>
<configuration>
<descriptors>
<descriptor>src/main/assembly/src.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
The first moduleSet I setup is
<moduleSet>
<includes>
<include>org.apache.uima:AlchemyAPIAnnotator</include>
<include>org.apache.uima:BSFAnnotator</include>
<include>org.apache.uima:ConceptMapper</include>
<include>org.apache.uima:ConfigurableFeatureExtractor</include>
<include>org.apache.uima:DictionaryAnnotator</include>
<include>org.apache.uima:FsVariables</include>
<include>org.apache.uima:Lucas</include>
<include>org.apache.uima:OpenCalaisAnnotator</include>
<include>org.apache.uima:PearPackagingAntTask</include>
<include>org.apache.uima:RegularExpressionAnnotator</include>
<include>org.apache.uima:SimpleServer</include>
<include>org.apache.uima:SnowballAnnotator</include>
<include>org.apache.uima:Solrcas</include>
<include>org.apache.uima:Tagger</include>
<include>org.apache.uima:TikaAnnotator</include>
<include>org.apache.uima:WhitespaceTokenizer</include>
<include>org.apache.uima:aggregate-addons</include>
<include>org.apache.uima:addons-osgi-runtime</include>
</includes>
which includes all the artifacts in top level directory.
THe problem is with the -osgi artifacts moduleSet:
<moduleSet>
<includes>
<include>org.apache.uima:AlchemyAPIAnnotator-osgi</include>
<include>org.apache.uima:BSFAnnotator-osgi</include>
<include>org.apache.uima:ConceptMapper-osgi</include>
<include>org.apache.uima:ConfigurableFeatureExtractor-osgi</include>
<include>org.apache.uima:DictionaryAnnotator-osgi</include>
<include>org.apache.uima:Lucas-osgi</include>
<include>org.apache.uima:OpenCalaisAnnotator-osgi</include>
<include>org.apache.uima:RegularExpressionAnnotator-osgi</include>
<include>org.apache.uima:SnowballAnnotator-osgi</include>
<include>org.apache.uima:Solrcas-osgi</include>
<include>org.apache.uima:Tagger-osgi</include>
<include>org.apache.uima:TikaAnnotator-osgi</include>
<include>org.apache.uima:WhitespaceTokenizer-osgi</include>
</includes>
<sources>
the problem is that with outputDirectory it seems one can only specify a
module relative path, so for example with:
<outputDirectory>addons-osgi-runtime</outputDirectory>
the source package will contain a directory
AlchemyAPIAnnotator-osgi/addons-osgi-runtime/ containing pom and notice of
AlchemyAPIAnnotator-osgi.
With the <directory></directory> element one can specify which directory of
a module maintain in the output package.
I also tried to manipulate existing examples from [1] but so far the only
way of having a working source package was by explicitly declaring each
module fileset.
Tommaso
[1] :
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-module-set-topics.html
2011/6/17 Marshall Schor <ms...@schor.com>
> My first try - of switching to just using the standard assembly descriptor
> -
> failed, because that requires following the convention that the top pom
> have the
> other poms as subdirectories under it.
>
> I'm going to investigate the modulesets approach next.
>
> -Marshall
>
> On 6/16/2011 8:39 AM, Marshall Schor wrote:
> > I'll take a look...
> >
> > On 6/16/2011 5:25 AM, Tommaso Teofili wrote:
> >> Hi all,
> >> I'm working on creating a new assembly descriptor for the source release
> >> with the proposed idea of using two separate modulesets, one for
> >> aggregate-addons and one for addons-osgi-runtime.
> >> However so far I didn't manage to find a proper assembly configuration
> to
> >> make sure the source release package look like the SVN tag and can be
> built
> >> once unzipped.
> >> Explicitly declaring one fileset per module with proper outputDirectory
> will
> >> work for sure but I wonder if you can help me find a smarter way.
> >> Thanks in advance,
> >> Tommaso
> >>
>
Re: uima-addons source release configuration
Posted by Tommaso Teofili <to...@gmail.com>.
I've made the basic steps to move the addons/trunk/aggregate-addons/pom.xml
to addons/trunk/pom.xml , now I think we should move the uima-addons/pom.xml
(the distr artifact) configuration inside an apache-release in the top level
pom.xml, also the src/main/assembly directory will need to be moved from
addons/trunk/uima-addons to addons/trunk/.
Regards,
Tommaso
2011/6/17 Marshall Schor <ms...@schor.com>
> +1 from me to try this :-)
>
> Better to conform rather than configure, as they say in "maven".
>
> The addons package will be a nice isolated test to verify everything works.
>
> Tommmaso - let me know if you want me to help in doing this (e.g., moving
> stuff
> in svn).
>
> -Marshall
>
> On 6/17/2011 3:54 AM, Tommaso Teofili wrote:
> > Nice idea, I'm +1 both for the purposes of the distribution package and
> for
> > the ease of use on a fresh checkout.
> > Tommaso
> >
> > 2011/6/17 Jukka Zitting <ju...@gmail.com>
> >
> >> Hi,
> >>
> >> On Fri, Jun 17, 2011 at 3:35 AM, Marshall Schor <ms...@schor.com> wrote:
> >>> My first try - of switching to just using the standard assembly
> >> descriptor -
> >>> failed, because that requires following the convention that the top pom
> >> have the
> >>> other poms as subdirectories under it.
> >> Which begs the question, why don't we simply do UIMA-1967 [1]?
> >>
> >> [1] https://issues.apache.org/jira/browse/UIMA-1967
> >>
> >> BR,
> >>
> >> Jukka Zitting
> >>
>
Re: uima-addons source release configuration
Posted by Marshall Schor <ms...@schor.com>.
+1 from me to try this :-)
Better to conform rather than configure, as they say in "maven".
The addons package will be a nice isolated test to verify everything works.
Tommmaso - let me know if you want me to help in doing this (e.g., moving stuff
in svn).
-Marshall
On 6/17/2011 3:54 AM, Tommaso Teofili wrote:
> Nice idea, I'm +1 both for the purposes of the distribution package and for
> the ease of use on a fresh checkout.
> Tommaso
>
> 2011/6/17 Jukka Zitting <ju...@gmail.com>
>
>> Hi,
>>
>> On Fri, Jun 17, 2011 at 3:35 AM, Marshall Schor <ms...@schor.com> wrote:
>>> My first try - of switching to just using the standard assembly
>> descriptor -
>>> failed, because that requires following the convention that the top pom
>> have the
>>> other poms as subdirectories under it.
>> Which begs the question, why don't we simply do UIMA-1967 [1]?
>>
>> [1] https://issues.apache.org/jira/browse/UIMA-1967
>>
>> BR,
>>
>> Jukka Zitting
>>
Re: uima-addons source release configuration
Posted by Tommaso Teofili <to...@gmail.com>.
Nice idea, I'm +1 both for the purposes of the distribution package and for
the ease of use on a fresh checkout.
Tommaso
2011/6/17 Jukka Zitting <ju...@gmail.com>
> Hi,
>
> On Fri, Jun 17, 2011 at 3:35 AM, Marshall Schor <ms...@schor.com> wrote:
> > My first try - of switching to just using the standard assembly
> descriptor -
> > failed, because that requires following the convention that the top pom
> have the
> > other poms as subdirectories under it.
>
> Which begs the question, why don't we simply do UIMA-1967 [1]?
>
> [1] https://issues.apache.org/jira/browse/UIMA-1967
>
> BR,
>
> Jukka Zitting
>
Re: uima-addons source release configuration
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Jun 17, 2011 at 3:35 AM, Marshall Schor <ms...@schor.com> wrote:
> My first try - of switching to just using the standard assembly descriptor -
> failed, because that requires following the convention that the top pom have the
> other poms as subdirectories under it.
Which begs the question, why don't we simply do UIMA-1967 [1]?
[1] https://issues.apache.org/jira/browse/UIMA-1967
BR,
Jukka Zitting
Re: uima-addons source release configuration
Posted by Marshall Schor <ms...@schor.com>.
My first try - of switching to just using the standard assembly descriptor -
failed, because that requires following the convention that the top pom have the
other poms as subdirectories under it.
I'm going to investigate the modulesets approach next.
-Marshall
On 6/16/2011 8:39 AM, Marshall Schor wrote:
> I'll take a look...
>
> On 6/16/2011 5:25 AM, Tommaso Teofili wrote:
>> Hi all,
>> I'm working on creating a new assembly descriptor for the source release
>> with the proposed idea of using two separate modulesets, one for
>> aggregate-addons and one for addons-osgi-runtime.
>> However so far I didn't manage to find a proper assembly configuration to
>> make sure the source release package look like the SVN tag and can be built
>> once unzipped.
>> Explicitly declaring one fileset per module with proper outputDirectory will
>> work for sure but I wonder if you can help me find a smarter way.
>> Thanks in advance,
>> Tommaso
>>
Re: uima-addons source release configuration
Posted by Marshall Schor <ms...@schor.com>.
I'll take a look...
On 6/16/2011 5:25 AM, Tommaso Teofili wrote:
> Hi all,
> I'm working on creating a new assembly descriptor for the source release
> with the proposed idea of using two separate modulesets, one for
> aggregate-addons and one for addons-osgi-runtime.
> However so far I didn't manage to find a proper assembly configuration to
> make sure the source release package look like the SVN tag and can be built
> once unzipped.
> Explicitly declaring one fileset per module with proper outputDirectory will
> work for sure but I wonder if you can help me find a smarter way.
> Thanks in advance,
> Tommaso
>