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
https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/
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
Source:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
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
you?
Therefor I'd like to bring this over to d...@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.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
