Transitive dependency problem with commons-logging

[Martin Gilday <ma...@imap.cc>]

Hi,
I have a problem with transitive dependencies with commons-logging and
trying to figure out if it is a bug or a misunderstanding on my part
about how transitive works.
I have a definition of a top level dependency on commons-logging 1.1
<dependency>
<groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.1</version>
 <scope>provided</scope>
</dependency>

I have the scope as provided as it is a web app and is provided by
JBoss.
I then have a dependency on WebWork 2.2.2.  This has a transitive
dependency on an older version of commons-logging so I add an exclusion
(I am also laziliy copying and pasting this into other POM where I am
not using commons-logging, which is another, bad, reason for the
exclusion)
<dependency>
 <groupId>opensymphony</groupId>
 <artifactId>webwork</artifactId>
 <version>2.2.2</version>
 <exclusions>
  <exclusion>
   <groupId>commons-logging</groupId>
   <artifactId>commons-logging</artifactId>
  </exclusion>
  <exclusion>
   <groupId>commons-collections</groupId>
   <artifactId>commons-collections</artifactId>
  </exclusion>
  <exclusion>
   <groupId>org.springframework</groupId>
   <artifactId>spring-core</artifactId>
  </exclusion>
  <exclusion>
   <groupId>org.springframework</groupId>
   <artifactId>spring-context</artifactId>
  </exclusion>
  <exclusion>
   <groupId>org.springframework</groupId>
   <artifactId>spring-beans</artifactId>
  </exclusion>
  <exclusion>
   <groupId>org.springframework</groupId>
   <artifactId>spring-aop</artifactId>
  </exclusion>
 </exclusions>
</dependency>

My assuption was this exclusion would prevent the commons-logging
depdency defined in the WebWork POM from bubbling up, but then still use
my top level definition.  When I do this and do a "clean compile" I get
compilation errors regarding logging such as cannot find symbol
LogFactory.  If I take the exclusion out then everything is happy.

Has anyone got any pointers as to where my problem lies?  Is it a
problem with the WebWork POM, my POM definition or a bug?

Thanks for any help,
Martin Gilday.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Transitive dependency problem with commons-logging

[Byron du Preez <by...@devstream.net>]

Hi Martin

Afraid I don't have a solution, but I do seem to be experiencing a similar issue.

In my case, I am trying to stop acegi and spring-richclient from dragging in
older versions of spring with exclusions and getting mixed results.
Excluding spring on acegi dependency seems to block it from transitively
downloading spring 1.2.7.
However, excluding both acegi and spring on the spring-richclient
dependencies, suddenly causes maven2 to throw compiler errors - despite
the fact that I have explicity added the spring dependencies to the
project - both before and after the exclusions (in desperation).

"The type ...HttpInvokerProxyFactoryBean cannot be resolved.
It is indirectly referenced from required .class files"
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor
           .executeGoals(DefaultLifecycleExecutor.java:559)
        ...
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: 
Compiler errors : error at public abstract class RemoteServiceBaseFactory
extends ...BasicAuthHttpInvokerProxyFactoryBean

One difference between the two is that acegi depends on spring, but
spring-richclient depends on spring and it depends on acegi (which 
depends on spring).

So, basically it looks like maven2's exclusions is broken in some scenarios.
Explicitly including spring-remoting has no affect on the compiler error.
Perhaps classworlds is creating a special class loader for the dependency 
and its exclusions, which is unaware of the parent class loader that should
contain the version you require.

Best regards
Byron
P.S. mvn -X helps to see dependency chains



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org