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 <c...@qos.ch> > > 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 > >
