commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <>
Subject Re: commons-logging version 0.0.0-EMPTY
Date Tue, 19 May 2009 10:18:58 GMT

Dennis Lundberg wrote:
> Ceki Gulcu wrote:
>> Hello all,
>> I have created an empty Maven project with groupId "commons-logging",
>> artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
>> little content (around 500 bytes) in the whole project. This is to be
>> expected as the original aim was to produce an empty jar file.
>> For the actual "source code", see
>> Anyway, as discussed previously, how do we go about publishing this
>> empty jar on ibiblio (Maven's central repository). Is a vote
>> warranted, or would that be premature?
> Hi Ceki
> I'm not convinced that the approach that you are proposing will work
> seamlessly for most of our users, i.e. those that really want to have
> commons-logging in their classpath.

Seamlessly? The whole idea is for the version 0.0 to be declared
explicitly in the end-user's project POM. We do not want version 0.0
to override a later version *seamlessly*. Those who wish to have
a rel commons-logging on their class path do not have to do anything.

We are making use of Maven's notion of "nearest definition"

   # 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


The key phrase being:

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

Forgive me for asking, but were you aware of the above. And if you
were, would you care to explain a scenario in mind which is troubling

> Therefor I'd like to bring this over to dev@maven.a.o to get some input
> from the people who knows the inner workings of Maven. I will bring any
> feedback back here later on.

Please do.

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