On 09.08.2011 11:57, Christian Grobmeier wrote:
Another option is to try to work with Ceki to address some of the
concerns of the commons community with regards to using slf4j.
* There is a hassle with too many jars for dependencies with slf4j.
* Every time Ceki goes on vacation everything stops
Emmanuel Bourg wrote:
Ceki Gulcu a écrit :
Other people than me are already using Paul's bridge or
SLF4JBridgeHandler which use the same principle. Did they complain about
performance issues?
As far as I know, SLF4JBridgeHandler is used to bridge a small number
of logging events gene
Emmanuel Bourg wrote:
Ceki Gulcu a écrit :
Redirecting to jul from log4j assumes that you have log4j.jar on your
class path. When you direct from jul to log4j, which is the case you
mentioned, then you need log4j.jar plus the bridge code which is
located in a different artifact (apache-jul
Emmanuel Bourg wrote:
Ceki Gulcu a écrit :
And everything ends in log4j, where redirecting JUL requires just one
line in your configuration.
How so?
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
Redirecting to jul from log4j assumes that
Emmanuel Bourg wrote:
Ralph Goers a écrit :
I disagree on both counts. Logging is critical to everything.
Debugging problems can be quite difficult if logging isn't done well.
Commons Logging isn't all that sophisticated IMO and using JUL as a
facade isn't all that practical and just becaus
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
sebb wrote:
Given that this process has stalled
It has indeed stalled. Nevertheless, it was an interesting
discussion. The openness demonstrated by this group is unusual as it
is refreshing. It seems that ultimately the status quo (inaction) won
the day which is not entirely surprising in the
Niall Pemberton wrote:
So the alternative to releasing the version to the main maven repo is
to setup a one-off repo just containing this 0.0-EMPTY version of
logging and users who want to depend on it adding that repo to their
pom along with the 0.0-EMPTY dependency. Thats just a few extra lin
Jörg Schaible wrote:
Hi Ceki,
Ceki Gulcu wrote at Dienstag, 19. Mai 2009 22:00:
Dennis Lundberg wrote:
Yes I'm aware of that. My concern is for those people who don't know
about that. What will happen if they declare
commons-logging:commons-logging without a version in the
Dennis Lundberg wrote:
Yes I'm aware of that. My concern is for those people who don't know
about that. What will happen if they declare
commons-logging:commons-logging without a version in their POM? Or
declare the special token LATEST as a version for commons-logging? Will
they get 1.1.1 or 0.
Jochen Wiedmann wrote:
On Tue, May 19, 2009 at 2:21 PM, Mario Ivankovits wrote:
Nice would be, as opposite to the , to have a global ,
no?
That way, problems like this are sorted out once and for all.
+1
Jochen, you do realize that global exclusions would suffer from the same
problem
nicolas de loof wrote:
A library autor that MAY use cl-0.0 to remove commons-logging from
dependency tree and use SLF4J will anyway have a dependency on cl-over-sfl4j
that solves the ClassNotFoundException
Good point but what if the end-user wanted to use commons-logging proper and not
SLF4J?
Hi Mario,
Global exclusions in Maven would provide a solution with essentially
the same problems and dangers as with 0.0-EMPTY. Anyway, global exclusions have
been requested in the past but afaik nothing came of it. Hence,
0.0-EMPTY.
Mario Ivankovits wrote:
Hmmm
Couldn't we ask the maven
Jörg Schaible wrote:
Forgive me for asking, but were you aware of the above. And if you
were, would you care to explain a scenario in mind which is troubling
you?
First: The solution is perfect for a normal user i.e. somebody building an
application, not a library/framework. The problem star
Dennis Lundberg wrote:
Ceki Gulcu wrote:
Hello all,
I have created an empty Maven project with groupId "commons-logging",
artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
little content (around 500 bytes) in the whole project. This is to be
expected as
The relevant element should have been inserted within element and not
. Issue solved now. Thank you for your help.
Ceki Gulcu wrote:
sebb wrote:
On 18/05/2009, Ceki Gulcu wrote:
sebb wrote:
I just tried, and using the "default" tags works OK for me.
What "default
sebb wrote:
On 18/05/2009, Ceki Gulcu wrote:
sebb wrote:
I just tried, and using the "default" tags works OK for me.
What "default" tags have you tried exactly?
The manifest ones I mentioned:
true
true
sebb wrote:
I just tried, and using the "default" tags works OK for me.
What "default" tags have you tried exactly?
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
Craig L Russell wrote:
Just for my information, why is it not desirable to package this as an
OSGi compliant jar?
Because we would not want an empty bundle containing no classes to
usurp the place of the real commons-logging OSGi bundle.
Also, why is the maven group id commons-logging and no
sebb wrote:
On 18/05/2009, c...@apache.org wrote:
Author: ceki
Date: Mon May 18 16:47:32 2009
New Revision: 776006
URL: http://svn.apache.org/viewvc?rev=776006&view=rev
Log:
name correction
Huh?
My bad. I has forgotten to save my changes in the editor before committing.
--
Ceki Gül
Hello,
Thank you for this suggestion. Unfortunately, adding references to parent pom,
and creates a
manifest file which includes OSGi directives, which is really not desirable.
I changed the contents of the name element to "Commons Logging".
sebb wrote:
Thanks, although IMO it would hav
sebb wrote:
On 18/05/2009, Ceki Gulcu wrote:
sebb wrote:
It would be useful if the Manifest included the following details:
Implementation-Title: commons-logging
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 0.0.0
sebb wrote:
It would be useful if the Manifest included the following details:
Implementation-Title: commons-logging
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 0.0.0-EMPTY
Specification-Title: commons-logging
Specificatio
Matt Benson wrote:
For the actual "source code", see
https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/
Just to point out: the final location of this "code" should AIUI BE a branch under logging/branches... the current structure isn't harming anything at the moment, however
nicolas de loof wrote:
The POM should include SCM path, url to commons-logging site and licensing
metadata
Done. Note that I've used the url for for svn in commons/proper/trunk.
Maybe you could also include the blog extract as description / comment. The
description explains the jar is empty
Hello all,
I have created an empty Maven project with groupId "commons-logging",
artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
little content (around 500 bytes) in the whole project. This is to be
expected as the original aim was to produce an empty jar file.
For the actual
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 reliabl
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
em
sebb wrote:
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 dependency
(or dependencyManagement)
- this don't break the existin
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
acts 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
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 t
sebb wrote:
Has anyone tried declaring commons logging as system ?
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ü
Log
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-loggin
Mark Thomas wrote:
Sorry if I wasn't clear. I intended that the slf4j jars and the third
party jars were all in WEB-INF/lib
My concern in this scenario is more that this j.u.l, as part of the JRE,
will be loaded by the System class loader and hence loggers are
registered JVM wide rather than pe
Mark Thomas wrote:
Two web applications both using slf4j with java.util.logging and both
using a third party library that has a logger called "MyLogger".
When web app one uses the library, slf4j will return - via a call to
j.u.l.getLogger() - a new logger called MyLogger. When web app two use
On 2009-04-22 16:17:52 GMT, John Bollinger wrote:
> Furthermore, it seems clear that the class loading issues CL has
> exhibited, though mitigated in recent releases, are probably going to
> continue to present problems for some CL 1.x uses for the foreseeable
> future. (The irony of a convenie
37 matches
Mail list logo
