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 2010/05/12 00:43:41 UTC
packaging dependencies with distributions
For the various distributions, we package "immediate" dependencies. In
the past, I think that we have not included transitive dependencies,
because many components we depend on have lots of dependencies of their
own, which are not used and not needed for our particular use.
The new build system is continuing this tradition; if there is a
dependency of a dependency that you need, you would need to declare it
as a "direct" dependency of your POM being packaged.
One "advantage" of this is that it makes explicit in the POM what is
being included, which helps in reviewing Licenses and Notice
requirements that could flow from these dependencies.
Does this seem reasonable? I'm happy to change this approach if others
have a better idea about this.
-Marshall
Re: packaging dependencies with distributions
Posted by Pablo Duboue <pa...@gmail.com>.
On Wednesday 12 May 2010, Marshall Schor wrote:
> On 5/12/2010 7:44 AM, Thilo Götz wrote:
> > On 5/12/2010 11:44, Tommaso Teofili wrote:
> >> 2010/5/12 Thilo Götz <tw...@gmx.de>
> >>
> >>> IMO, we should explicitly list the dependencies we ship.
> >>> Otherwise every release we'll have a lot of work checking
> >>> that our packages don't contain any unwanted libraries.
This will also make easier for Linux distributions now carrying UIMA, e.g.,
Debian:
http://ftp-master.debian.org/new/uimaj_2.3.0-1.html
Re: packaging dependencies with distributions
Posted by Marshall Schor <ms...@schor.com>.
On 5/12/2010 7:44 AM, Thilo Götz wrote:
>
> On 5/12/2010 11:44, Tommaso Teofili wrote:
>
>> 2010/5/12 Thilo Götz <tw...@gmx.de>
>>
>>
>>> IMO, we should explicitly list the dependencies we ship.
>>> Otherwise every release we'll have a lot of work checking
>>> that our packages don't contain any unwanted libraries.
>>>
>>>
>>>
>> I am +1, how would you suggest to do that? Apart from the POM dependencies
>> list would you put them inside (for example) the README file or something
>> else?
>>
> In the POM is fine. I just meant we should list them
> for ourselves, as developers, so we know and have control
> over what we introduce as dependencies.
>
> For our users, we have the usual NOTICE and LICENSE files,
> where we list 3rd party software that we bring with us.
> Those we need to maintain anyway; and listing the dependencies
> in the POM makes that task easier and less error prone. When
> you have to add dependencies manually in the POM, it reminds
> you to update the NOTICE and LICENSE files at the same time.
> At least the release manager will have an easier job making
> sure those files are up to date.
>
+1. There's also a new "convention" in the standard Apache parent pom
that sticks in a list of transitive dependencies into every Jar's
META-INF in a new folder called "DEPENDENCIES", generated from the
dependency info, using some Velocity Macro stuff.
These are *more* than we ship, because we don't include by default *all*
transitive dependencies in our lib/.
For example, if you run the new maven build system (which I just checked
in - another note coming), and look at the uimaj-as-activemq project,
for instance, and look inside the Jar that is built, you will see there
inside META-INF, the file DEPENDENCIES and it looks something like this
(parts elided):
// ------------------------------------------------------------------
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// ------------------------------------------------------------------
UIMA-AS: uimaj-as-activemq
From: 'an unknown organization'
- jmdns activemq:jmdns:jar:1.0-RC2
- jaxp-api activesoap:jaxp-api:jar:1.3
- AOP alliance (http://aopalliance.sourceforge.net)
aopalliance:aopalliance:jar:1.0
License: Public Domain
- avalon-framework avalon-framework:avalon-framework:jar:4.1.3
. . . (elided)
From: 'Apache Software Foundation' (http://www.apache.org/)
- ActiveIO :: Core
(http://incubator.apache.org/activemq/activeio-core/)
org.apache.activemq:activeio-core:jar:3.0.0-incubator
License: The Apache Software License, Version 2.0
(http://www.apache.org/licenses/LICENSE-2.0.txt)
- ActiveMQ :: Console (http://activemq.apache.org/activemq-console/)
org.apache.activemq:activemq-console:jar:4.1.1
License: The Apache Software License, Version 2.0
(http://www.apache.org/licenses/LICENSE-2.0.txt)
. . . (elided)
From: 'The Apache Software Foundation' (http://www.apache.org/)
- UIMA-AS: uimaj-as-core (http://incubator.apache.org/uima)
org.apache.uima:uimaj-as-core:jar:2.3.1-SNAPSHOT
License: The Apache Software License, Version 2.0
(http://www.apache.org/licenses/LICENSE-2.0.txt)
. . . (elided)
-Marshall
> --Thilo
>
>
>> Cheers.
>> Tommaso
>>
>>
>
>
Re: packaging dependencies with distributions
Posted by Thilo Götz <tw...@gmx.de>.
On 5/12/2010 11:44, Tommaso Teofili wrote:
> 2010/5/12 Thilo Götz <tw...@gmx.de>
>
>>
>> IMO, we should explicitly list the dependencies we ship.
>> Otherwise every release we'll have a lot of work checking
>> that our packages don't contain any unwanted libraries.
>>
>>
> I am +1, how would you suggest to do that? Apart from the POM dependencies
> list would you put them inside (for example) the README file or something
> else?
In the POM is fine. I just meant we should list them
for ourselves, as developers, so we know and have control
over what we introduce as dependencies.
For our users, we have the usual NOTICE and LICENSE files,
where we list 3rd party software that we bring with us.
Those we need to maintain anyway; and listing the dependencies
in the POM makes that task easier and less error prone. When
you have to add dependencies manually in the POM, it reminds
you to update the NOTICE and LICENSE files at the same time.
At least the release manager will have an easier job making
sure those files are up to date.
--Thilo
>
> Cheers.
> Tommaso
>
Re: packaging dependencies with distributions
Posted by Tommaso Teofili <to...@gmail.com>.
>
>
>
> On 5/12/2010 00:43, Marshall Schor wrote:
> > For the various distributions, we package "immediate" dependencies. In
> > the past, I think that we have not included transitive dependencies,
> > because many components we depend on have lots of dependencies of their
> > own, which are not used and not needed for our particular use.
> >
> > The new build system is continuing this tradition; if there is a
> > dependency of a dependency that you need, you would need to declare it
> > as a "direct" dependency of your POM being packaged.
> >
> > One "advantage" of this is that it makes explicit in the POM what is
> > being included, which helps in reviewing Licenses and Notice
> > requirements that could flow from these dependencies.
> >
> > Does this seem reasonable?
>
+1 for me too
2010/5/12 Thilo Götz <tw...@gmx.de>
>
> IMO, we should explicitly list the dependencies we ship.
> Otherwise every release we'll have a lot of work checking
> that our packages don't contain any unwanted libraries.
>
>
I am +1, how would you suggest to do that? Apart from the POM dependencies
list would you put them inside (for example) the README file or something
else?
Cheers.
Tommaso
Re: packaging dependencies with distributions
Posted by Thilo Götz <tw...@gmx.de>.
+1
IMO, we should explicitly list the dependencies we ship.
Otherwise every release we'll have a lot of work checking
that our packages don't contain any unwanted libraries.
--Thilo
On 5/12/2010 00:43, Marshall Schor wrote:
> For the various distributions, we package "immediate" dependencies. In
> the past, I think that we have not included transitive dependencies,
> because many components we depend on have lots of dependencies of their
> own, which are not used and not needed for our particular use.
>
> The new build system is continuing this tradition; if there is a
> dependency of a dependency that you need, you would need to declare it
> as a "direct" dependency of your POM being packaged.
>
> One "advantage" of this is that it makes explicit in the POM what is
> being included, which helps in reviewing Licenses and Notice
> requirements that could flow from these dependencies.
>
> Does this seem reasonable? I'm happy to change this approach if others
> have a better idea about this.
>
> -Marshall
>