commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [all] maven group ids
Date Mon, 21 Aug 2006 18:47:48 GMT
Tomasz Pik wrote:
> On 8/20/06, Dennis Lundberg <dennisl@apache.org> wrote:
>> Tomasz Pik wrote:
>> > On 8/16/06, Dennis Lundberg <dennisl@apache.org> wrote:
>> >
>> >> > Yes, but instead of transiting something, that depends on other 
>> commons
>> >> > IMHO something without dependencies should be transited first.
>> >> > In other words, first thing to be done should be a graph of
>> >> dependencies
>> >> > between various commons packages and those without dependencies
>> >> > should be migrated first. I guess commons-lang is a good candidate
>> >> here,
>> >> > not configuration that depdends on many other (not migrated yet)
>> >> > components.
>> >>
>> >> What would we gain from this? A transition of component A will not
>> >> include updating existing commons-dependencies in component A to 
>> the new
>> >> ones with the new groupId. That will require a new release of that
>> >> component A. If fact we don't even have to wait for a release of a
>> >> component to do this.
>> >>
>> >> There is a good reason for *not* picking commons-lang or
>> >> commons-logging, two components without dependencies on other commons
>> >> components, as the first component to transition. That is that both 
>> are
>> >> on ibiblio's top 10 downloads list. I had link to it before but can't
>> >> seem to find it now, sorry. If we do it wrong there then all hell will
>> >> break loose. It'd be better to choose a "medium used" component.
>> >
>> > But this means, that all of those users, that downloading those top10
>> > jars in near future will have obosolete jars.
>>
>> They are *not* obsolete. They are relocated. They still function in
>> exactly the same way as before. The only difference is that there is a
>> relocation section in the pom that indicates to Maven 2 that this
>> project has changed one or more of groupId, artifactId or version.
>>
>> > Maven is not re-downloading nonSNAPSHOT artifacts so...
>> > Let's imagine I'm a new maven user having project with a dependency on
>> > commons-lang:commons-lang-2.1 and maven will download it for me.
>> > Some time later this package will be relocated to
>> > org.apache.commons.lang:commons-lang:2.1 (or similar).
>> > After that there'll be new, let's say acegi v1.4 depending on this 
>> 'new'
>> > commons-lang (org.apache....:commons-lang:2.1) and I need this acegi
>> > in my project.
>> > So after adding dependency on acegi maven will download
>> > org.apache.commons.lang:commons-lang:2.1 and won't download
>> > commons-lang:commons-lang:2.1 (which should result as relocation
>> > info) and finally, maven will be adding those two commons-lang jars
>> > into classpath, copy into WEB-INF/lib and so on.
>>
>> This was one of the tests that I performed when testing this. It is a
>> problem only for Maven 1 which does not handle relocations at all. In
>> Maven 2 this is handled transparently and you will not get two jars in
>> your WEB-INF/lib, only one.
>>
>> > All of this till the time I'll manually remove
>> > commons-lang:commons-lang:2.1
>> > from my repository so maven will be forced to reload them (and will
>> > download relocation info then).
>>
>> It is true that Maven 2 does not re-download something once it has
>> successfully downloaded it, but that has no impact on this discussion.
> 
> It has some impact for final users...
> 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?

<snip/>

-- 
Dennis Lundberg

---------------------------------------------------------------------
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