Ceki Gulcu wrote: > > > 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.
I think you misunderstood me. I'm concerned for the people that want the real version of commons-logging on their class path. We do not want to mess with their builds. They should be able to continue using commons-logging like they always have, even after a potential 0.0 anti-artifact is released. > 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? Yes I'm aware of that. My concern is for those people who don't know about that. What will happen if they declare commons-logging:commons-logging without a version in their POM? Or declare the special token LATEST as a version for commons-logging? Will they get 1.1.1 or 0.0 or what? >> 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. Done http://www.nabble.com/Need-your-input-on-a-repository-%22hack%22-to23605666.html -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
