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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
