Dennis Lundberg wrote:
Tomasz Pik wrote:
On 8/21/06, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
