commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nicolas de loof <nicolas.del...@gmail.com>
Subject Re: sanctioning commons-logging version "99.0-does-not-exist"
Date Fri, 15 May 2009 09:44:29 GMT
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

I don't think such an empty "hack" jar is injurious to commons-logging
developers, this is just a required maven hack that recognize how
universally commons-logging is used ! To be fully community-compliant, we
must help users to choose as easily as possible a Logging facade, so
enabling or disabling commons-logging should NOT be a maven hell.

Nicolas

2009/5/15 Ceki Gulcu <ceki@qos.ch>

>
> Henri Yandell wrote:
>
>> On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu <ceki@qos.ch> wrote:
>>
>>> Hi Ralph and co,
>>>
>>> The issue has been raised on the Maven list about 5 times, and if I
>>> remember correctly, it was raised by yourself once or twice. However,
>>> I am not aware of any progress on the issue.
>>>
>>> Anyway, my request involves allowing commons-logging v99 to be
>>> published on ibiblio. This needs to be done once.
>>>
>>
>> Why ibiblio and not their own repository?
>>
>
> Ibiblio is the central maven repository which everyone proxies. You
> don't have to declare it specifically in pm.xml. More precisely, maven
> requires at least one default repository which is almost always a
> proxy of ibiblio, plus some additions. Currently, version
> "99-does-not-exist" is published within its own repository, which
> needs to be declared specifically by the user in pom.xml. I'd like to
> avoid this step (specific declaration) and also avoid adding a
> dependency on another external repository.
>
>  With the negative being that anyone who might use 'LATEST' (not that I
>> knew that was a Maven feature... must keep up) is going to find they
>> can't use commons-logging anymore because they're get a duff one?
>>
>
> Maven dependency resolution rules are non-trivial. Specifically
> declaring a dependency on commons-logging will override any
> declaration made in included dependencies. There this another rule
> which gives precedence to higher version numbers. However, unless I am
> wrong, local declaration trumps higher version numbers. So version 0.0
> would probably work for our purposes as long as it is declared locally.
>
> We'd need to check maven dependency resolution rules.
>
>  Dumb question time - why do the version numbers have to increase? I'm
>> not getting why 0.0 would fail, but if it does then it sounds like it
>> would be bad for a later commons-logging release. Now if we're
>> prepared to say there won't be another 1.1.x sure - but presumably we
>> (and everyone) wants room for a 1.1.2 if some serious bug shows up?
>>
>
> Given the above, version 0.0 would probably work. I could not follow
> your reasoning about later commons logging releases.
>
>  It would be
>>> discouraged in red and bold print against declaring version 99 in
>>> libraries. Only end users, or application builders, would be "allowed"
>>> to declare version 99.
>>>
>>
>> Where is it printed?
>>
>
> It would be printed wherever the version "99-does-not-exists" is
> documented. Certainly in SLF4J documentation and presumably in
> commons-logging documentation as well.
>
> > How would people not be allowed?
>
> "Allowed" was not the correct term. I should have said "highly
> discouraged".
>
>  We got into this mess because there wasn't a solution and we needed
>> something for Commons libraries. Personally I think there is gain in
>> gently end of lifeing Commons Logging in favour of a focused logging
>> project.
>>
>> What most of my confused email at getting at is not regarding gain but
>> loss - what do we lose by doing this. The ability to do another
>> release? I'm not understanding the negative.
>>
>
> Stating the obvious but since you asked: You would cede control of one
> part of a common component, in this case logging, to an external
> entity.  In most organizations such relinquishment would be
> unimaginable. Things may be different with a non-profit organization
> such as Apache. However, the human factor is still present. For
> instance, SLF4J does not follow the same collaborative model as found
> in Apache. Some developers may be turned off by such a difference.
>
>  Does sfl4j also need to release a v99? I'm very susceptible to getting
>> off of commons-logging and onto sfl4j (and will probably vote +1 on
>> that in Commons), but are we just exchanging one dependency pain for
>> another, or is there a way the issue can be solved in the long term?
>>
>
> I wish I had a satisfactory answer. It is well possible that one day
> version 99 would be required for SLF4J as well. It would be arrogant
> and self-indulgent to say that SLF4J solves all logging API problems
> once and for all. It does not. There is also no denying that with
> hindsight some parts of SLF4J would be designed differently. However,
> when compared to commons-logging, SLF4J's static binding mechanism is
> simpler not because its designer was smarter but because it caters for
> a simpler use-case. And in this particular case, simplicity implies
> robustness, a highly desirable property to have in a logging system.
>
> Coming back to your question, there is no guarantee that SLF4J won't
> bite some Apache Commons project in the tushie some time in the
> future.  I would however say that the likelihood for running into
> trouble is lower with SLF4J than with commons-logging.
>
>  Hen
>>
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message