sebb wrote:
On 15/05/2009, nicolas de loof <nicolas.del...@gmail.com> wrote:
I'm +1 to have a 0.0 version in central under commons-logging groupId.
 - this can't break the LATEST rule
 - this will only apply if user explicitly declare this version as dependency
 (or dependencyManagement)
 - this don't break the existing commosn-logging user-base
 - this avoid introducing some third party repo in POM, tahtn can introduce
 many other unexpected dependencies conflicts

+1, I agree 0.0 should be safe.
[I'm assuming it never becomes necessary to wrap-round to negative numbers!]

But does it actually work with transitive dependencies?

Yes, it does work with transitive dependencies. I have tested this just to be sure. Maven documentation is also fairly clear on the subject [1]:

# Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.4 it was not defined which one would win, but since Maven 2.0.5 it's the order in the declaration that counts: the first declaration wins.

* "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0

[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

The key phrase is:

You can always guarantee a version by declaring it explicitly in your project's 
POM.


AIUI, the original motivation for the 99 hack was to deal with
commons-logging dependencies in transitive dependencies, not for the
initial dependency.

Which is why the number had to be "later" than any other versions.

I suggested 0.0, but then withdrew it because it would not be "later",
but maybe it can be made to work.

As far as I can tell, except for the SNAPSHOT suffix, the version
number has little if any effect. It can be ignored for the purposes of
dependency resolution. However, I am not an expert and a more
knowledgeable person might want to chip in.

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to