On 8/20/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Tomasz Pik wrote:
> On 8/16/06, Dennis Lundberg <[EMAIL PROTECTED]> 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'.
> 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.
100% agree :)
Regards,
Tomek
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
