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 Sun, 20 Aug 2006 19:50:08 GMT
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.

> So finally I think that sooner those jars will be relocated there'll be 
> less
> users having problems like this.

As I said before I'm all for a quick transition, but since commons 
components are very widely used, we have to make sure that we do 
everything correctly.

> 
> Regards,
> Tomek
> 
> -- 
>> Dennis Lundberg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


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