commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <>
Subject Re: sanctioning commons-logging version "99.0-does-not-exist"
Date Fri, 15 May 2009 17:25:23 GMT

sebb wrote:
> On 15/05/2009, nicolas de loof <> 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
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


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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message