How to exclude commons logging dependency of spring with ivy?

Arne Burmeister picture Arne Burmeister · Jun 15, 2011 · Viewed 21k times · Source

I have a project build with ant using ivy for dependency management. I have no ivysetting file, but an ivy.xml with the following dependency (I want to use spring with slf4j instead of commons logging):

<configurations>
  <conf name="compile" />
  <conf name="runtime" extends="compile"/>
</configurations>
<dependencies>
  <dependency org="org.springframework" name="spring-webmvc" rev="3.0.5.RELEASE" conf="compile->default">
    <exclude org="commons-logging" name="commons-logging"/>
  </dependency>
  <dependency org="org.slf4j" name="slf4j-api" rev="1.6.1" conf="compile->default" />
  <dependency org="org.slf4j" name="jcl-over-slf4j" rev="1.6.1" conf="runtime->default" />
</dependencies>

But when resolving the compile configuration, commons-logging is resolved. I also tried to use the exclude on an explicit spring-core dependency but commons-logging is always placed into the compile classpath.

What is my fault? Isn't it that what Not Using Commons Logging describes for maven? Is it an ivy bug? Need I a special setting? Has ivy something cached? Any idea?

I use ant 1.8.2 and ivy 2.2.0, Using IvyDE in Eclipse has the same problem.

Answer

oers picture oers · Jun 16, 2011

Your usage of the <exclude /> seems to be broken for unkown reasons. I tried something similar on my pc and the following worked:
Try the top-level exclude (which is directly under <dependencies />:

    <dependencies>
      <dependency org="org.springframework" name="spring-webmvc" rev="3.0.5.RELEASE" conf="compile->default">
      </dependency>
      <dependency org="org.slf4j" name="slf4j-api" rev="1.6.1" conf="compile->default" />
      <dependency org="org.slf4j" name="jcl-over-slf4j" rev="1.6.1" conf="runtime->default" />
      <exclude org="commons-logging"/>
</dependencies>

I don't know why the other one is not working. There are some bugs in JIRA concerning exclude and circular dependencies, but that doesn't seem to fit this case. Maybe it's a real bug.