You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ceki Gulcu <ce...@qos.ch> on 2009/05/14 11:23:09 UTC
sanctioning commons-logging version "99.0-does-not-exist"
Hello all,
A large number of Maven projects declare commons-logging as a
dependency. Thus, if a developer wishes to use jcl-over-slf4j instead
of commons-logging, he or she would need to declare a commons-logging
exclusion in all of his/her dependencies which transitively depend on
commons-logging. This can be an error prone process. To alleviate the
pain, Erik van Oosten has developed a clever hack around this problem.
See http://tinyurl.com/2kds3v for details.
The idea is to publish empty artifacts which supposedly fulfill
dependencies for commons-logging without actually providing any
classes (hence the empty artifacts).
This approach works fine except that it requires the declaration of a
new repository in the project's pom.xml file. Moreover, the durability
of this repository is also questionable.
Would the Apache Commons community, out of courtesy to developers,
consent to commons-logging version "99.0-does-not-exist" to be
published in the main maven repository?
I understand that the Apache Commons has nothing to gain by
sanctioning work done elsewhere. However, since the ASF is a
non-profit organization I thought that my request might have a small
chance of being accepted.
Thank you for your response,
--
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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
Hi Erik,
Thank you for the information about the typo. Unfortunately, the
0.0.0-EMPTY initiative was shut down due to opposition by Jochen
Wiedmann and Rahul Akolkar among others. Other voices favorable to the
initiative were not heard or were not persistent enough.
Anyway, we'll have to resort to other techniques to solve this
issue. I suggest that we discuss those steps on the dev@slf4j
mailing list.
BR
Erik van Oosten wrote:
> Not sure where to report this. There is a tiny typo in
> https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/trunk/pom.xml
>
> Please search for the text "0.0.0-EMPPTY", with 2 P's.
>
> Regards,
> Erik.
>
>
> PS. Ceki, very good idea you presented in this thread.
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Erik van Oosten <e....@grons.nl>.
Not sure where to report this. There is a tiny typo in
https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/trunk/pom.xml
Please search for the text "0.0.0-EMPPTY", with 2 P's.
Regards,
Erik.
PS. Ceki, very good idea you presented in this thread.
Ceki Gulcu wrote:
>
> Henri Yandell wrote:
>>
>> I've given you karma for the sandbox. Make a logging branch in there
>> and it can be voted on for release into proper.
>
> Great. Thank you. I just successfully created
>
> https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/
>
>> Hen
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
--
View this message in context: http://www.nabble.com/-continuum--BUILD-SUCCESSFUL%3A-Commons---Commons-Pool---tp23536471p23941131.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
Henri Yandell wrote:
>
> I've given you karma for the sandbox. Make a logging branch in there
> and it can be voted on for release into proper.
Great. Thank you. I just successfully created
https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/
> 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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, May 17, 2009 at 9:50 AM, Ceki Gulcu <ce...@qos.ch> wrote:
>
>
> Henri Yandell wrote:
>
>> We're not actually ceding control though. I'm assuming the 0.0 or 99.0
>> version will be released through us etc etc. As you're an Apache
>> committer I don't see any reason why that should be an issue. If we
>> need to release a 0.0.0 (or whatever) later to fix an issue in the
>> empty pom, we could.
>
> True. BTW, thank you for rekindling this thread.
I'm a slow reader currently :)
>> In terms of helping sfl4j gain marketshare at commons-logging's loss -
>> more power to slf4j. You don't gain anything long term by
>> protectionism.
>
> I agree. However, you need to have a certain perspective to come to
> that realization.
>
>> Something for the Maven guys to try and solve before that day arrives I
>> guess.
>>
>> Wonder what Phil et al think to making DBCP dependent on SFL4J :)
>>
>> Anyway +1 to the 0.0 approach. I like the 'zero'ness of it to imply
>> that you're getting nothing, as opposed to 99 which feels more like
>> there is something there. As long as it fills your needs, and protects
>> from any LATEST issues it sounds like a win-win.
>
> Very good. I'll start working on this in a 0.0 branch and once done, submit
> for a vote on a release.
I've given you karma for the sandbox. Make a logging branch in there
and it can be voted on for release into proper.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
Henri Yandell wrote:
> We're not actually ceding control though. I'm assuming the 0.0 or 99.0
> version will be released through us etc etc. As you're an Apache
> committer I don't see any reason why that should be an issue. If we
> need to release a 0.0.0 (or whatever) later to fix an issue in the
> empty pom, we could.
True. BTW, thank you for rekindling this thread.
> In terms of helping sfl4j gain marketshare at commons-logging's loss -
> more power to slf4j. You don't gain anything long term by
> protectionism.
I agree. However, you need to have a certain perspective to come to
that realization.
> Something for the Maven guys to try and solve before that day arrives I guess.
>
> Wonder what Phil et al think to making DBCP dependent on SFL4J :)
>
> Anyway +1 to the 0.0 approach. I like the 'zero'ness of it to imply
> that you're getting nothing, as opposed to 99 which feels more like
> there is something there. As long as it fills your needs, and protects
> from any LATEST issues it sounds like a win-win.
Very good. I'll start working on this in a 0.0 branch and once done, submit for
a vote on a release.
> 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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, May 15, 2009 at 2:36 AM, Ceki Gulcu <ce...@qos.ch> wrote:
>
> Henri Yandell wrote:
>> 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.
We're not actually ceding control though. I'm assuming the 0.0 or 99.0
version will be released through us etc etc. As you're an Apache
committer I don't see any reason why that should be an issue. If we
need to release a 0.0.0 (or whatever) later to fix an issue in the
empty pom, we could.
In terms of helping sfl4j gain marketshare at commons-logging's loss -
more power to slf4j. You don't gain anything long term by
protectionism.
>> 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.
Something for the Maven guys to try and solve before that day arrives I guess.
Wonder what Phil et al think to making DBCP dependent on SFL4J :)
Anyway +1 to the 0.0 approach. I like the 'zero'ness of it to imply
that you're getting nothing, as opposed to 99 which feels more like
there is something there. As long as it fills your needs, and protects
from any LATEST issues it sounds like a win-win.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
sebb wrote:
> On 15/05/2009, nicolas de loof <ni...@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?
Yes, it does work with transitive dependencies. I have tested this just to be
sure. Maven documentation is also fairly clear on the subject [1]:
# Dependency mediation - this determines what version of a dependency will be
used when multiple versions of an artifact are encountered. Currently, Maven 2.0
only supports using the "nearest definition" which means that it will use the
version of the closest dependency to your project in the tree of dependencies.
You can always guarantee a version by declaring it explicitly in your project's
POM. Note that if two dependency versions are at the same depth in the
dependency tree, until Maven 2.0.4 it was not defined which one would win, but
since Maven 2.0.5 it's the order in the declaration that counts: the first
declaration wins.
* "nearest definition" means that the version used will be the closest one
to your project in the tree of dependencies, eg. if dependencies for A, B, and C
are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used
when building A because the path from A to D through E is shorter. You could
explicitly add a dependency to D 2.0 in A to force the use of D 2.0
[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
The key phrase is:
You can always guarantee a version by declaring it explicitly in your project's POM.
> 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.
As far as I can tell, except for the SNAPSHOT suffix, the version
number has little if any effect. It can be ignored for the purposes of
dependency resolution. However, I am not an expert and a more
knowledgeable person might want to chip in.
--
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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by sebb <se...@gmail.com>.
On 15/05/2009, nicolas de loof <ni...@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 <ce...@qos.ch>
>
>
> >
> > Henri Yandell wrote:
> >
> >> On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu <ce...@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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by nicolas de loof <ni...@gmail.com>.
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 <ce...@qos.ch>
>
> Henri Yandell wrote:
>
>> On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu <ce...@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
>
>
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
Henri Yandell wrote:
> On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu <ce...@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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu <ce...@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?
> Users who wish to exclude commons-logging would be doing so by
> explicitly including version 99 in their pom.xml file.
As long as we don't make a 100 right?
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?
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?
> 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?
How would people not be allowed?
> While there is some small danger in some component declaring version
> 99 in their pom.xml and this preventing the inclusion of
> commons-logging proper, any library developer with half-a-brain would
> refrain from doing that.
>
> Thus, the idea is to offer some additional comfort for those users
> wishing to exclude commons-logging. Admittedly, there is no gain for
> the Apache Commons community.
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.
> Thank you for taking my request into consideration.
Related subject.
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?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
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.
Users who wish to exclude commons-logging would be doing so by
explicitly including version 99 in their pom.xml file. 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.
While there is some small danger in some component declaring version
99 in their pom.xml and this preventing the inclusion of
commons-logging proper, any library developer with half-a-brain would
refrain from doing that.
Thus, the idea is to offer some additional comfort for those users
wishing to exclude commons-logging. Admittedly, there is no gain for
the Apache Commons community.
Thank you for taking my request into consideration.
Ralph Goers wrote:
> I would suggest bringing this up on the Maven dev list. I could see
> adding this as a feature to 3.0 to allow artifacts to be "redirected" to
> a replacement artifact.
>
> On May 14, 2009, at 2:23 AM, Ceki Gulcu wrote:
>
>> Hello all,
>>
>> A large number of Maven projects declare commons-logging as a
>> dependency. Thus, if a developer wishes to use jcl-over-slf4j instead
>> of commons-logging, he or she would need to declare a commons-logging
>> exclusion in all of his/her dependencies which transitively depend on
>> commons-logging. This can be an error prone process. To alleviate the
>> pain, Erik van Oosten has developed a clever hack around this problem.
>>
>> See http://tinyurl.com/2kds3v for details.
>>
>> The idea is to publish empty artifacts which supposedly fulfill
>> dependencies for commons-logging without actually providing any
>> classes (hence the empty artifacts).
>>
>> This approach works fine except that it requires the declaration of a
>> new repository in the project's pom.xml file. Moreover, the durability
>> of this repository is also questionable.
>>
>> Would the Apache Commons community, out of courtesy to developers,
>> consent to commons-logging version "99.0-does-not-exist" to be
>> published in the main maven repository?
>>
>> I understand that the Apache Commons has nothing to gain by
>> sanctioning work done elsewhere. However, since the ASF is a
>> non-profit organization I thought that my request might have a small
>> chance of being accepted.
>>
>> Thank you for your response,
>>
>> --
>> 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
>
>
--
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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ralph Goers <ra...@dslextreme.com>.
I would suggest bringing this up on the Maven dev list. I could see
adding this as a feature to 3.0 to allow artifacts to be "redirected"
to a replacement artifact.
On May 14, 2009, at 2:23 AM, Ceki Gulcu wrote:
> Hello all,
>
> A large number of Maven projects declare commons-logging as a
> dependency. Thus, if a developer wishes to use jcl-over-slf4j instead
> of commons-logging, he or she would need to declare a commons-logging
> exclusion in all of his/her dependencies which transitively depend on
> commons-logging. This can be an error prone process. To alleviate the
> pain, Erik van Oosten has developed a clever hack around this problem.
>
> See http://tinyurl.com/2kds3v for details.
>
> The idea is to publish empty artifacts which supposedly fulfill
> dependencies for commons-logging without actually providing any
> classes (hence the empty artifacts).
>
> This approach works fine except that it requires the declaration of a
> new repository in the project's pom.xml file. Moreover, the durability
> of this repository is also questionable.
>
> Would the Apache Commons community, out of courtesy to developers,
> consent to commons-logging version "99.0-does-not-exist" to be
> published in the main maven repository?
>
> I understand that the Apache Commons has nothing to gain by
> sanctioning work done elsewhere. However, since the ASF is a
> non-profit organization I thought that my request might have a small
> chance of being accepted.
>
> Thank you for your response,
>
> --
> 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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, May 14, 2009 at 11:23 AM, Ceki Gulcu <ce...@qos.ch> wrote:
> Would the Apache Commons community, out of courtesy to developers,
> consent to commons-logging version "99.0-does-not-exist" to be
> published in the main maven repository?
No, never do that! It possibly breaks any algorithm that attempts to
find something like the "latest" version.
Jochen
--
Don't trust a government that doesn't trust you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
sebb wrote:
>
> Has anyone tried declaring commons logging as <scope>system</scope> ?
>
> Won't that stop it being added to the classpath?
I have not tries this but wouldn't declaring a dependency in the
system scope force the artifact to be present on the file system of
the host to begin with?
--
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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by nicolas de loof <ni...@gmail.com>.
I myself use slf4j and this "99" hack
Using en empty "commons-logging-0.0-null.jar" would NOT break the LATEST
keyword resolution and could be forced from project <dependencyManagement>
(with provided scope)
This would be a nice solution to globaly exclude xommons-logging without
breaking existing builds
Nicolas
2009/5/14 sebb <se...@gmail.com>
> On 14/05/2009, Jochen Wiedmann <jo...@gmail.com> wrote:
> > On Thu, May 14, 2009 at 11:35 AM, sebb <se...@gmail.com> wrote:
> >
> > > Has anyone tried declaring commons logging as <scope>system</scope> ?
> >
> >
> > Beg your pardon, but this is against any use of transitive
> > dependencies. Likewise for "provided", of course. If it is a
> > dependency, then it is. If anyone else intends to replace it, okay,
> > but this is the users decision.
> >
>
> Not sure what you mean about transitive dependencies here.
>
> AIUI, what the 99.0-does-not-exist is trying to do is to provide a
> fake resolution for people who want to use jcl-over-slf4j instead of
> commons-logging.
>
> The referenced blog had a posting suggesting using
> <scope>provided</scope> but apparently that still adds commons logging
> as a dependency.
>
> I was suggesting trying "system" scope instead.
> If people want to try that for their systems, well why not?
>
> But I agree with others that version 99 is a really bad idea.
>
> Perhaps "0.0-does-not-exist" might be a more acceptable solution, or
> maybe "0.0-null-version" as it does need to exist.
>
> > Jochen
> >
> > --
> > Don't trust a government that doesn't trust you.
> >
> > ---------------------------------------------------------------------
> >
> > 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
>
>
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by sebb <se...@gmail.com>.
On 14/05/2009, sebb <se...@gmail.com> wrote:
> On 14/05/2009, Jochen Wiedmann <jo...@gmail.com> wrote:
> > On Thu, May 14, 2009 at 11:35 AM, sebb <se...@gmail.com> wrote:
> >
> > > Has anyone tried declaring commons logging as <scope>system</scope> ?
> >
> >
> > Beg your pardon, but this is against any use of transitive
> > dependencies. Likewise for "provided", of course. If it is a
> > dependency, then it is. If anyone else intends to replace it, okay,
> > but this is the users decision.
> >
>
>
> Not sure what you mean about transitive dependencies here.
>
> AIUI, what the 99.0-does-not-exist is trying to do is to provide a
> fake resolution for people who want to use jcl-over-slf4j instead of
> commons-logging.
>
> The referenced blog had a posting suggesting using
> <scope>provided</scope> but apparently that still adds commons logging
> as a dependency.
>
> I was suggesting trying "system" scope instead.
> If people want to try that for their systems, well why not?
>
> But I agree with others that version 99 is a really bad idea.
>
> Perhaps "0.0-does-not-exist" might be a more acceptable solution, or
> maybe "0.0-null-version" as it does need to exist.
Realised just too late:
Of course that won't work, as the version number has to be higher than
any existing ones.
I think that adding a fake jar to the repository where it may be
*accidentally* picked up is not a good solution to this problem.
It might be OK if the jar could only be used if deliberately selected
by the user.
>
> > Jochen
> >
> > --
> > Don't trust a government that doesn't trust you.
> >
> > ---------------------------------------------------------------------
> >
> > 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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by sebb <se...@gmail.com>.
On 14/05/2009, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Thu, May 14, 2009 at 11:35 AM, sebb <se...@gmail.com> wrote:
>
> > Has anyone tried declaring commons logging as <scope>system</scope> ?
>
>
> Beg your pardon, but this is against any use of transitive
> dependencies. Likewise for "provided", of course. If it is a
> dependency, then it is. If anyone else intends to replace it, okay,
> but this is the users decision.
>
Not sure what you mean about transitive dependencies here.
AIUI, what the 99.0-does-not-exist is trying to do is to provide a
fake resolution for people who want to use jcl-over-slf4j instead of
commons-logging.
The referenced blog had a posting suggesting using
<scope>provided</scope> but apparently that still adds commons logging
as a dependency.
I was suggesting trying "system" scope instead.
If people want to try that for their systems, well why not?
But I agree with others that version 99 is a really bad idea.
Perhaps "0.0-does-not-exist" might be a more acceptable solution, or
maybe "0.0-null-version" as it does need to exist.
> Jochen
>
> --
> Don't trust a government that doesn't trust you.
>
> ---------------------------------------------------------------------
>
> 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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, May 14, 2009 at 11:35 AM, sebb <se...@gmail.com> wrote:
> Has anyone tried declaring commons logging as <scope>system</scope> ?
Beg your pardon, but this is against any use of transitive
dependencies. Likewise for "provided", of course. If it is a
dependency, then it is. If anyone else intends to replace it, okay,
but this is the users decision.
Jochen
--
Don't trust a government that doesn't trust you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Ceki Gulcu <ce...@qos.ch>.
Jörg Schaible wrote:
>
> Use scope "provided" - if any. Actually if people use a master pom and
> declare CL in the depMgmt section with this scope, it should do the trick.
Provided just means that the artifact will not be included in the
packaged application. However, during development, within the IDE,
e.g. Eclipse, the artifact will still be present.
Assuming "99.0-does-not-exist" is technically a sound solution, my
question is whether this community would consent to officially
sanctioning it, even if it is detrimental to its "market-share".
--
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
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote at Donnerstag, 14. Mai 2009 11:35:
> On 14/05/2009, Ceki Gulcu <ce...@qos.ch> wrote:
>> Hello all,
>>
>> A large number of Maven projects declare commons-logging as a
>> dependency. Thus, if a developer wishes to use jcl-over-slf4j instead
>> of commons-logging, he or she would need to declare a commons-logging
>> exclusion in all of his/her dependencies which transitively depend on
>> commons-logging. This can be an error prone process. To alleviate the
>> pain, Erik van Oosten has developed a clever hack around this problem.
>>
>> See http://tinyurl.com/2kds3v for details.
>>
>> The idea is to publish empty artifacts which supposedly fulfill
>> dependencies for commons-logging without actually providing any
>> classes (hence the empty artifacts).
>>
>> This approach works fine except that it requires the declaration of a
>> new repository in the project's pom.xml file. Moreover, the durability
>> of this repository is also questionable.
>
> Has anyone tried declaring commons logging as <scope>system</scope> ?
>
> Won't that stop it being added to the classpath?
Use scope "provided" - if any. Actually if people use a master pom and
declare CL in the depMgmt section with this scope, it should do the trick.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: sanctioning commons-logging version "99.0-does-not-exist"
Posted by sebb <se...@gmail.com>.
On 14/05/2009, Ceki Gulcu <ce...@qos.ch> wrote:
> Hello all,
>
> A large number of Maven projects declare commons-logging as a
> dependency. Thus, if a developer wishes to use jcl-over-slf4j instead
> of commons-logging, he or she would need to declare a commons-logging
> exclusion in all of his/her dependencies which transitively depend on
> commons-logging. This can be an error prone process. To alleviate the
> pain, Erik van Oosten has developed a clever hack around this problem.
>
> See http://tinyurl.com/2kds3v for details.
>
> The idea is to publish empty artifacts which supposedly fulfill
> dependencies for commons-logging without actually providing any
> classes (hence the empty artifacts).
>
> This approach works fine except that it requires the declaration of a
> new repository in the project's pom.xml file. Moreover, the durability
> of this repository is also questionable.
Has anyone tried declaring commons logging as <scope>system</scope> ?
Won't that stop it being added to the classpath?
> Would the Apache Commons community, out of courtesy to developers,
> consent to commons-logging version "99.0-does-not-exist" to be
> published in the main maven repository?
>
> I understand that the Apache Commons has nothing to gain by
> sanctioning work done elsewhere. However, since the ASF is a
> non-profit organization I thought that my request might have a small
> chance of being accepted.
>
> Thank you for your response,
>
> --
> 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