On 15/05/2009, nicolas de loof <nicolas.del...@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 <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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
