commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [all] maven group ids
Date Sun, 27 Aug 2006 14:54:52 GMT
Dennis Lundberg wrote:
> Tomasz Pik wrote:
>> On 8/21/06, Dennis Lundberg <dennisl@apache.org> 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
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/
>> 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:
> 
>   http://www.mvnregistry.com/search/depended_upon_artifacts
> 

How do we proceed here? Do all agree with this proposed solution? And if 
so: when would this change happen?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message