Henri Yandell wrote:
On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu <c...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
