From dev-return-114215-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Fri May 15 10:55:09 2009 Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 3835 invoked from network); 15 May 2009 10:55:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 May 2009 10:55:09 -0000 Received: (qmail 55216 invoked by uid 500); 15 May 2009 10:55:08 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 55094 invoked by uid 500); 15 May 2009 10:55:08 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 55081 invoked by uid 99); 15 May 2009 10:55:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2009 10:55:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 209.85.219.210 as permitted sender) Received: from [209.85.219.210] (HELO mail-ew0-f210.google.com) (209.85.219.210) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2009 10:54:58 +0000 Received: by ewy6 with SMTP id 6so2420629ewy.42 for ; Fri, 15 May 2009 03:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Gnr4Y63YAgH1RWB3B9+BjPsDEPreHDlsGTUULiGAWFE=; b=eXs0Zhy1rlFgA1wskZZaJdfLEvm+immAINsRfKfRE5KCFdhk7mwTn/hTsWv0KKU94C giaDcptzQYFt8+82P+/aG3SUBjdyNinQD4sdUePpiZE35rpMA/7/Mmje7UM48Ew7MV2y wHiFGsxMiH3Yaq1XmyCBvI4uN/DKII9e3QTuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=KRqGYV7Zzr1I8Tm6dExgaDL4SAjiiddhQ6OKPjQBFcK1tVHm4MNQCy90VyKf+Vm72m LeMIWu0lLHZTrE+3/cOspVxYXCHIbjQdtlXpa0Il1iRJbBkb+Y6HuhBvSK5NFQkEJph0 SjNsv7n4N26K93tBYmEB+OEJtjEJWNu8zmbng= MIME-Version: 1.0 Received: by 10.216.26.205 with SMTP id c55mr1214937wea.1.1242384876817; Fri, 15 May 2009 03:54:36 -0700 (PDT) In-Reply-To: <4c39e3030905150244q20002acfq14555fc08f9efa5a@mail.gmail.com> References: <27286235.01242290018223.JavaMail.continuum@vmbuild.apache.org> <4A0BE2FD.9090705@qos.ch> <4A0C2EB7.8020000@qos.ch> <31cc37360905141930l552ce39eidde4fdf084083923@mail.gmail.com> <4A0D3788.6060100@qos.ch> <4c39e3030905150244q20002acfq14555fc08f9efa5a@mail.gmail.com> Date: Fri, 15 May 2009 11:54:36 +0100 Message-ID: <25aac9fc0905150354k10e4860p5076ec6ed01fb5a6@mail.gmail.com> Subject: Re: sanctioning commons-logging version "99.0-does-not-exist" From: sebb To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On 15/05/2009, nicolas de loof 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 depend= ency > (or dependencyManagement) > - this don't break the existing commosn-logging user-base > - this avoid introducing some third party repo in POM, tahtn can introdu= ce > 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, w= e > 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 > > > > > > Henri Yandell wrote: > > > >> On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu 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 "allowe= d" > >>> 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 bu= t > >> 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 gettin= g > >> 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=FClc=FC > > Logback: The reliable, generic, fast and flexible logging framework fo= r > > 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