commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [all] maven group ids
Date Fri, 25 Aug 2006 16:21:42 GMT
Tomasz Pik wrote:
> On 8/21/06, Dennis Lundberg <> wrote:
>> Tomasz Pik wrote:
>> > Maven won't 'redownload' commons-lang:commons-lang:2.1
>> > and if  threre'll be something that depends on
>> > org.apache.commons:commons-lang:2.2.
>> > Maven won't know that it's only a version difference, for Maven
>> > those components are a completly different packages so both
>> > will be added to classpath, packaged into wars and so on.
>> > And for example for most servlet containers I've observed, that
>> > they added jars in alphabetized order, so commons-lang:2.1 will 'win'.
>> Do you have a suggestion for how we should handle this in commons?
> This cann't be handled/solved in general in commons.
> My point is that it would be better to avoid some kind of 'propagation'
> of this problem. Whole disussion starts around new release of
> commnons-collections which for example depends on commons-lang:2.1
> And all I'm suggesting is that those packages should be relocated first,
> so commons-collections will depend on org.apache.commons:commons-lang:2.1,
> not commons-lang:commons-lang:2.1. So, if there'll be a org.apache.commons:
> commons-lang:2.2 and I want to use this because there's something new and
> neat, I can just add this dependency to my project and this will win over
> transitive 2.1 depenency from commons-collections.
> Other solution will be not relocate anything (which probably won't be 
> accepted
> by repository manages...) or do not define those dependencies in pom.xml
> files (also not the best solution).
> One more thing: having this commons-lang:commons-lang:2.1 dependency
> in org.apache.commons:commons-colletions as a dependency will make
> a bit strange situation: there'll be a commons package in
> that will depend on other commons project, which is not available there.
> I know there's a lot of packages, that depends on commons-xx;commons-xx
> packages (which are on ibiblio) but <veryPersonalOpionon>IMHO it's not
> a good situation</veryPersonalOpinion>

Having let your comments sink in, I now understand what your point is. I 
think that the best solution would be to switch groupId:s for all 
components in-between releases. Say that we switch groupId:s today (only 
as an example). Then every release after today needs to update the 
groupId:s for all dependencies on other commons components. How does 
that sound?

I found the top-10-list link I was talking about earlier in this thread. 
It's actually a top-25-list featuring commons-logging, 
commons-collections, commons-lang and commons-beanutils:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message