commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: sanctioning commons-logging version "99.0-does-not-exist"
Date Fri, 15 May 2009 10:54:36 GMT
On 15/05/2009, nicolas de loof <nicolas.deloof@gmail.com> wrote:
> 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

+1, I agree 0.0 should be safe.
[I'm assuming it never becomes necessary to wrap-round to negative numbers!]

But does it actually work with transitive dependencies?

AIUI, the original motivation for the 99 hack was to deal with
commons-logging dependencies in transitive dependencies, not for the
initial dependency.

Which is why the number had to be "later" than any other versions.

I suggested 0.0, but then withdrew it because it would not be "later",
but maybe it can be made to work.

>  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.

I disagree - I don't think Commons *needs* to do anything to be
"community-compliant".

But if there is something that can be done which does not adversely
affect existing Commons users and developers, then yes, that is
something we should consider.

>  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
>  >
>  >
>

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


Mime
View raw message