commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: commons-logging version 0.0.0-EMPTY
Date Tue, 19 May 2009 18:51:45 GMT
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 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.

Done

http://www.nabble.com/Need-your-input-on-a-repository-%22hack%22-to23605666.html


-- 
Dennis Lundberg

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


Mime
View raw message