20070204 Sunday February 04, 2007

Maven 2 hates Commons Logging It's true that most people hate commons-logging, but Maven 2 hates it even more. There are many open source projects that use this library, so you're likely to depend on it when you never intended to. Of course, this is Maven 2's transitive dependencies fault - but currently there's no option to turn transitivity off. I tried changing to SLF4J, but that causes some Maven plugins to fail.

Since the Maven team refuses to fix this (even though it's an *obvious* exception to their rule about not changing anything), I've fixed it myself. The AppFuse repo has a fixed version of commons-logging's pom.xml. To get the fixed version of commons-logging, delete it from your local repo, then add AppFuse's repository to your pom.xml:

    <repositories>
        <repository>
            <id>appfuse</id>
            <url>http://static.appfuse.org/repository</url>
        </repository>
    </repositories>

Since the burden of this issue clearly rests upon the shoulders of the commons-logging developers - can we please get a new release with a fixed pom? Pretty please?

Update: I tried to get slf4j to work again today. While I succeeded, I found a critical bug. The bug is that log messages don't print out the method name, just debug(), info() or whatever from your classes. It's possible to fix this by using slf4j instead of clogging. However, that won't help you get method names printed when cranking up the logging for 3rd party libraries like Spring and Hibernate. Since this won't be fixed, it seems better to stick with commons-logging. I doubt I'd have any luck getting all the libraries that AppFuse uses to move away from commons-logging. Posted in Java at Feb 04 2007, 10:43:15 PM MST 10 Comments

Comments:

I've also had a lot of problems with commons logging for this exact same reason however a couple of days ago I found out about the ability to exclude dependencies from another project's import. This is the POM import I've used for commons logging &

<dependency>
	<groupId>commons-logging</groupId>
	<artifactId>commons-logging</artifactId>
	<version>1.1</version>
	<scope>compile</scope>
	<exclusions>
		<exclusion>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
		</exclusion>
		<exclusion>
			<groupId>logkit</groupId>
			<artifactId>logkit</artifactId>
		</exclusion>
		<exclusion>
			<groupId>avalon-framework</groupId>
			<artifactId>avalon-framework</artifactId>
		</exclusion>
		<exclusion>
			<groupId>javax.servlet</groupId>
			<artifactId>servlet-api</artifactId>
		</exclusion>
	</exclusions>
</dependency>
Using this does not prevent you from re-importing a dependency but it does mean that you can get rid of any problems that might arise.

Posted by Andy Yates on February 05, 2007 at 02:49 AM MST #

Of course, another option is to explicitly exclude commons-logging, and add dependency for jcl104-over-slf4j, which is basically a slf4j who implements commons-logging interface. You can read more about it at http://www.slf4j.org/manual.html#gradual

Posted by David Rabinowitz on February 05, 2007 at 11:55 AM MST #

David - I tried that. The hibernate3-maven-plugin barfs with a NoClassDefFoundError. I sent e-mails (this morning) to both the slf4j and mojo mailing lists to try to find a resolution.

Posted by Matt Raible on February 05, 2007 at 12:05 PM MST #

After exchanging emails with Matt, it looks like he did not include any binding as a dependency. Matt thought that since slf4j-simple was declared in the pom file of jcl-over-slf4j as a dependency, it would be included by transitivity. However, the slf4j-simple dependency is marked with the provided scope, so that it is *not* included transitivitely.

Posted by Ceki Gulcu on February 05, 2007 at 12:36 PM MST #

They just need to cut a new release, i don't know why they wait so long, i imagine not enought users have bothered them.

And adding your own modified commons-logging to your repo is really a bad idea.
- if i already have it cached (most likely) i won't get it from your repo
- if i get it from you other projects may not work


So the easiest solution would be to create org.appfuse.thirparty commons-logging pom (type pom) that depends on commons-logging 1.1 with all the exclusions, and make appfuse use that one until 1.1.1 is released

Posted by Carlos Sanchez on February 06, 2007 at 04:20 PM MST #

I myself had the issue that commons-logging was importing servlet-api in my ear thus effectively making my webapp not work. I think it's a crime not to fix this and add servlet-api as provided, as it makes webapps fail TODAY instead of other apps that might fail but probably no-one will notice. Why in the hell's name would anyone want to import servlet-api into a project is beyond me. Just go with the flow Sanchez and correct this blatant mistake!

Posted by Srgjan Srepfler on February 09, 2007 at 01:49 PM MST #

The SLF4J bug mentioned by Matt has been fixed in SLF4J version 1.3.

Posted by Ceki Gulcu on February 22, 2007 at 06:41 AM MST #

Thanks for posting this info Matt, I was quite puzzled and you and the posters were really helpful :)

Posted by Fabricio on May 11, 2007 at 11:28 AM MDT #

Matt, The Commons Logging team is preparing the 1.1.1 release. As far as I can tell, the bug will be fixed in Commons Logging 1.1.1: https://issues.apache.org/jira/browse/LOGGING-113

Posted by Commons Logging user on July 30, 2007 at 10:20 PM MDT #

Commons Logging 1.1.1 does indeed fix the problem. Thanks for the pointer.

Posted by Jason Harrop on April 02, 2008 at 12:34 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is a Web Architect who enjoys developing applications with open source technologies. Contact me for rates.
« December 2008
SunMonTueWedThuFriSat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today

Recent Entries

Tag Cloud