bug? strange resolution of commons-logging dependency

[Lucas Bergman]

I ran into a strange dependency resolution problem at work, which a
colleague and I whittled down to a fairly simple test case.  Consider
the following POM:

  <project xmlns="http://maven.apache.org/POM/4.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                               http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>htmlunitbug</artifactId>
    <packaging>jar</packaging>
    <version>2.71828</version>

    <build>
      <pluginManagement>
        <plugins>
          <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
              <source>1.5</source>
              <target>1.5</target>
            </configuration>
          </plugin>
        </plugins>
      </pluginManagement>
    </build>

    <dependencies>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.6</version>
        <scope>test</scope>
      </dependency>
      <dependency>
        <groupId>net.sourceforge.htmlunit</groupId>
        <artifactId>htmlunit</artifactId>
        <version>2.5</version>
        <scope>test</scope>
      </dependency>
      <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-ehcache</artifactId>
        <version>3.3.1.GA</version>
        <scope>runtime</scope>
      </dependency>
      <!-- hibernate-ehcache depends on a very old version. -->
      <dependency>
        <groupId>net.sf.ehcache</groupId>
        <artifactId>ehcache</artifactId>
        <version>1.6.0</version>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </project>

And, consider the following test class:

  import com.gargoylesoftware.htmlunit.WebClient;
  import org.junit.Test;

  public class MyTest {
      @Test public void test() { new WebClient(); }
  }

Running this test with Maven 2.1.0 fails:

  java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
  [ ... ]

The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
(compile-scope) dependency, so this seems wrong.  There seems to be
some interaction between that POM and the dependent POMs.  Indeed:

  1.  Moving the htmlunit dependency element below the
  hibernate-ehcache and ehcache dependency elements causes
  commons-logging to be a test-scope dependency, and the test
  succeeds.  This seems bizarre.  Should the ordering of dependency
  elements ever matter?

  2.  Adding an exclusion of commons-logging to the hibernate-ehcache
  dependency causes the test to succeed.  I tried this, because the
  hibernate-ehcache POM depends on commons-logging version
  99.0-does-not-exist, a rather famous JBoss kludge[1].

  3.  Removing the dependency on hibernate-ehcache causes the test to
  succeed.  This is perhaps not surprising, in light of (2).

  4.  Removing the dependency on ehcache causes the test to succeed.
  This is very strange to me, since ehcache directly depends on
  commons-logging 1.0.4; it contains no funny business.

Am I doing something wrong here?  I'll be happy to follow this through
with a JIRA ticket, if somebody here can convince me that I haven't
done anything stupid; I'm not a very confident Maven user.

Best,
-- Lucas

Footnotes:
[1]  http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html

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

[Jörg Schaible-2]

Lucas Bergman wrote:

> I ran into a strange dependency resolution problem at work, which a
> colleague and I whittled down to a fairly simple test case.  Consider
> the following POM:
>
>   <project xmlns="http://maven.apache.org/POM/4.0.0"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>                                http://maven.apache.org/maven-v4_0_0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>com.example</groupId>
>     <artifactId>htmlunitbug</artifactId>
>     <packaging>jar</packaging>
>     <version>2.71828</version>
>
>     <build>
>       <pluginManagement>
>         <plugins>
>           <plugin>
>             <artifactId>maven-compiler-plugin</artifactId>
>             <configuration>
>               <source>1.5</source>
>               <target>1.5</target>
>             </configuration>
>           </plugin>
>         </plugins>
>       </pluginManagement>
>     </build>
>
>     <dependencies>
>       <dependency>
>         <groupId>junit</groupId>
>         <artifactId>junit</artifactId>
>         <version>4.6</version>
>         <scope>test</scope>
>       </dependency>
>       <dependency>
>         <groupId>net.sourceforge.htmlunit</groupId>
>         <artifactId>htmlunit</artifactId>
>         <version>2.5</version>
>         <scope>test</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.hibernate</groupId>
>         <artifactId>hibernate-ehcache</artifactId>
>         <version>3.3.1.GA</version>
>         <scope>runtime</scope>
>       </dependency>
>       <!-- hibernate-ehcache depends on a very old version. -->
>       <dependency>
>         <groupId>net.sf.ehcache</groupId>
>         <artifactId>ehcache</artifactId>
>         <version>1.6.0</version>
>         <scope>runtime</scope>
>       </dependency>
>     </dependencies>
>   </project>
>
> And, consider the following test class:
>
>   import com.gargoylesoftware.htmlunit.WebClient;
>   import org.junit.Test;
>
>   public class MyTest {
>       @Test public void test() { new WebClient(); }
>   }
>
> Running this test with Maven 2.1.0 fails:
>
>   java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
>   [ ... ]
>
> The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
> (compile-scope) dependency, so this seems wrong.  There seems to be
> some interaction between that POM and the dependent POMs.

By default commons-logging tries to discover the logger in use on its own.
Somehow a log4j is available from somewhere else, but the classpath does
not match. Therefore disable the discovery by either providing a
commons-logging.properties file in src/test/resources or set a system
property in the surefire configuration for your tests.

See
http://commons.apache.org/logging/commons-logging-1.1.1/guide.html#Configuration

- Jörg


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

[Lucas Bergman]

Jörg Schaible wrote:

> Lucas Bergman wrote:
> > Running this test with Maven 2.1.0 fails:
> >
> >   java.lang.NoClassDefFoundError:
> >       org/apache/commons/logging/LogFactory
> >   [ ... ]
> >
> > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
> > (compile-scope) dependency, so this seems wrong.  There seems to
> > be some interaction between that POM and the dependent POMs...
>
> By default commons-logging tries to discover the logger in use on
> its own.  Somehow a log4j is available from somewhere else, but the
> classpath does not match. Therefore disable the discovery by either
> providing a commons-logging.properties file in src/test/resources or
> set a system property in the surefire configuration for your tests.

Thank you for the answer, but I don't think that that is the problem.
The commons-logging library never gets as far as configuration
sniffing, since Maven doesn't include it in the classpath at all.
Running Maven with -X confirms that commons-logging-*.jar is never
included in the classpath when running tests, unless I do one or more
of the rain dances I detailed in my original message[1].

The more I think about this, the more this seems like a Maven bug.

Best,
-- Lucas

Footnotes:
[1]  http://www.mail-archive.com/users@.../msg99747.html

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

[Jörg Schaible-2]

Lucas Bergman wrote at Montag, 29. Juni 2009 15:25:

> Jörg Schaible wrote:
>> Lucas Bergman wrote:
>> > Running this test with Maven 2.1.0 fails:
>> >
>> >   java.lang.NoClassDefFoundError:
>> >       org/apache/commons/logging/LogFactory
>> >   [ ... ]
>> >
>> > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
>> > (compile-scope) dependency, so this seems wrong.  There seems to
>> > be some interaction between that POM and the dependent POMs...
>>
>> By default commons-logging tries to discover the logger in use on
>> its own.  Somehow a log4j is available from somewhere else, but the
>> classpath does not match. Therefore disable the discovery by either
>> providing a commons-logging.properties file in src/test/resources or
>> set a system property in the surefire configuration for your tests.
>
> Thank you for the answer, but I don't think that that is the problem.
> The commons-logging library never gets as far as configuration
> sniffing, since Maven doesn't include it in the classpath at all.
> Running Maven with -X confirms that commons-logging-*.jar is never
> included in the classpath when running tests, unless I do one or more
> of the rain dances I detailed in my original message[1].
>
> The more I think about this, the more this seems like a Maven bug.

See http://jira.codehaus.org/browse/MNG-4207 for background.

- Jörg


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

[Lucas Bergman]

Jörg Schaible wrote:

> Lucas Bergman wrote:
> > Jörg Schaible wrote:
> > > Lucas Bergman wrote:
> > > > Running this test with Maven 2.1.0 fails:
> > > >
> > > >   java.lang.NoClassDefFoundError:
> > > >       org/apache/commons/logging/LogFactory
> > > >   [ ... ]
> > > >
> > > > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
> > > > (compile-scope) dependency, so this seems wrong.  There seems to
> > > > be some interaction between that POM and the dependent POMs...
> > >
> > > By default commons-logging tries to discover the logger in use
> > > on its own.  Somehow a log4j is available from somewhere else,
> > > but the classpath does not match. Therefore disable the
> > > discovery by either providing a commons-logging.properties file
> > > in src/test/resources or set a system property in the surefire
> > > configuration for your tests.
> >
> > Thank you for the answer, but I don't think that that is the
> > problem.  The commons-logging library never gets as far as
> > configuration sniffing, since Maven doesn't include it in the
> > classpath at all.  Running Maven with -X confirms that
> > commons-logging-*.jar is never included in the classpath when
> > running tests, unless I do one or more of the rain dances I
> > detailed in my original message[1].
> >
> > The more I think about this, the more this seems like a Maven bug.
>
> See http://jira.codehaus.org/browse/MNG-4207 for background.

I understand what you're saying, but that's not it.  Look at the error
above: the commons-logging classes are not even loaded, let alone
configured.  Am I missing something?

-- Lucas

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

[dennisl-2]

Lucas Bergman wrote:

> I ran into a strange dependency resolution problem at work, which a
> colleague and I whittled down to a fairly simple test case.  Consider
> the following POM:
>
>   <project xmlns="http://maven.apache.org/POM/4.0.0"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>                                http://maven.apache.org/maven-v4_0_0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>com.example</groupId>
>     <artifactId>htmlunitbug</artifactId>
>     <packaging>jar</packaging>
>     <version>2.71828</version>
>
>     <build>
>       <pluginManagement>
>         <plugins>
>           <plugin>
>             <artifactId>maven-compiler-plugin</artifactId>
>             <configuration>
>               <source>1.5</source>
>               <target>1.5</target>
>             </configuration>
>           </plugin>
>         </plugins>
>       </pluginManagement>
>     </build>
>
>     <dependencies>
>       <dependency>
>         <groupId>junit</groupId>
>         <artifactId>junit</artifactId>
>         <version>4.6</version>
>         <scope>test</scope>
>       </dependency>
>       <dependency>
>         <groupId>net.sourceforge.htmlunit</groupId>
>         <artifactId>htmlunit</artifactId>
>         <version>2.5</version>
>         <scope>test</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.hibernate</groupId>
>         <artifactId>hibernate-ehcache</artifactId>
>         <version>3.3.1.GA</version>
>         <scope>runtime</scope>
>       </dependency>
>       <!-- hibernate-ehcache depends on a very old version. -->
>       <dependency>
>         <groupId>net.sf.ehcache</groupId>
>         <artifactId>ehcache</artifactId>
>         <version>1.6.0</version>
>         <scope>runtime</scope>
>       </dependency>
>     </dependencies>
>   </project>
>
> And, consider the following test class:
>
>   import com.gargoylesoftware.htmlunit.WebClient;
>   import org.junit.Test;
>
>   public class MyTest {
>       @Test public void test() { new WebClient(); }
>   }
>
> Running this test with Maven 2.1.0 fails:
>
>   java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
>   [ ... ]
>
> The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
> (compile-scope) dependency, so this seems wrong.  There seems to be
> some interaction between that POM and the dependent POMs.  Indeed:
>
>   1.  Moving the htmlunit dependency element below the
>   hibernate-ehcache and ehcache dependency elements causes
>   commons-logging to be a test-scope dependency, and the test
>   succeeds.  This seems bizarre.  Should the ordering of dependency
>   elements ever matter?

It does matter, but only for artifacts at the same distance from the
dependency.

>   2.  Adding an exclusion of commons-logging to the hibernate-ehcache
>   dependency causes the test to succeed.  I tried this, because the
>   hibernate-ehcache POM depends on commons-logging version
>   99.0-does-not-exist, a rather famous JBoss kludge[1].

That is your problem. What this does is mess the dependency-tree. It
removes commons-logging from the dependency tree because that version
"99.0-..." is larger than the latest current release of commons-logging.
The "99.0-..." version should *never ever* reach end users. It can
*only* be used by internal project.

>   3.  Removing the dependency on hibernate-ehcache causes the test to
>   succeed.  This is perhaps not surprising, in light of (2).
>
>   4.  Removing the dependency on ehcache causes the test to succeed.
>   This is very strange to me, since ehcache directly depends on
>   commons-logging 1.0.4; it contains no funny business.
>
> Am I doing something wrong here?  I'll be happy to follow this through
> with a JIRA ticket, if somebody here can convince me that I haven't
> done anything stupid; I'm not a very confident Maven user.
>
> Best,
> -- Lucas
>
> Footnotes:
> [1]  http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Dennis Lundberg

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

[Jörg Schaible-2]

Lucas Bergman wrote at Montag, 29. Juni 2009 18:11:

> Jörg Schaible wrote:
>> Lucas Bergman wrote:
>> > Jörg Schaible wrote:
>> > > Lucas Bergman wrote:
>> > > > Running this test with Maven 2.1.0 fails:
>> > > >
>> > > >   java.lang.NoClassDefFoundError:
>> > > >       org/apache/commons/logging/LogFactory
>> > > >   [ ... ]
>> > > >
>> > > > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
>> > > > (compile-scope) dependency, so this seems wrong.  There seems to
>> > > > be some interaction between that POM and the dependent POMs...
>> > >
>> > > By default commons-logging tries to discover the logger in use
>> > > on its own.  Somehow a log4j is available from somewhere else,
>> > > but the classpath does not match. Therefore disable the
>> > > discovery by either providing a commons-logging.properties file
>> > > in src/test/resources or set a system property in the surefire
>> > > configuration for your tests.
>> >
>> > Thank you for the answer, but I don't think that that is the
>> > problem.  The commons-logging library never gets as far as
>> > configuration sniffing, since Maven doesn't include it in the
>> > classpath at all.  Running Maven with -X confirms that
>> > commons-logging-*.jar is never included in the classpath when
>> > running tests, unless I do one or more of the rain dances I
>> > detailed in my original message[1].
>> >
>> > The more I think about this, the more this seems like a Maven bug.
>>
>> See http://jira.codehaus.org/browse/MNG-4207 for background.
>
> I understand what you're saying, but that's not it.  Look at the error
> above: the commons-logging classes are not even loaded, let alone
> configured.  Am I missing something?

You've been right, I should have read your question closer. See Dennis'
answer. Actually there was an attempt to release an official empty
commons-logging at Apache recently and it was tunred down exactly because
we could foresee this problem you're facing now :-/

- Jörg


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

[Ceki Gulcu]

Jörg Schaible wrote:

> You've been right, I should have read your question closer. See Dennis'
> answer. Actually there was an attempt to release an official empty
> commons-logging at Apache recently and it was tunred down exactly because
> we could foresee this problem you're facing now :-/

Note that we wanted to release version 0.0-EMPTY, not version 99. One
could argue that releasing 0.0-EMPTY could have prevented this issue
from occurring.

> - Jörg

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

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

[Jörg Schaible-2]

Hi Ceki,

Ceki Gulcu wrote at Dienstag, 30. Juni 2009 16:45:

>
>
> Jörg Schaible wrote:
>
>> You've been right, I should have read your question closer. See Dennis'
>> answer. Actually there was an attempt to release an official empty
>> commons-logging at Apache recently and it was tunred down exactly because
>> we could foresee this problem you're facing now :-/
>
> Note that we wanted to release version 0.0-EMPTY, not version 99. One
> could argue that releasing 0.0-EMPTY could have prevented this issue
> from occurring.

Since the algorithm takes the distance into account, it could have been
happened also:

A depends on B, C
B depends on D
C depends on CL-0.0-EMPTY
D depends on CL-1.1.1

C' dep to CL-0.0-EMPTY is nearer -> compilation fails.

As said, it's a good solution for an end application, but not for libraries
used by others ;-)

- Jörg


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

[Lucas Bergman]

Dennis Lundberg wrote:

> Lucas Bergman wrote:
> > Running this test with Maven 2.1.0 fails:
> >
> >   java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> >   [ ... ]
> >
> > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
> > (compile-scope) dependency, so this seems wrong.  There seems to
> > be some interaction between that POM and the dependent POMs.
> > Indeed:
> >
> >   [ ... ]
> >
> >   2.  Adding an exclusion of commons-logging to the
> >   hibernate-ehcache dependency causes the test to succeed.  I
> >   tried this, because the hibernate-ehcache POM depends on
> >   commons-logging version 99.0-does-not-exist, a rather famous
> >   JBoss kludge[1].
> >
> > [ ... ]
> >
> > Footnotes:
> > [1]  http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html
>
> That is your problem. What this does is mess the dependency-tree. It
> removes commons-logging from the dependency tree because that
> version "99.0-..." is larger than the latest current release of
> commons-logging.  The "99.0-..." version should *never ever* reach
> end users. It can *only* be used by internal project.

Thanks for the input.  Are you saying that the dependency of the
hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
I'm sympathetic to that view, but I just want to be sure.  To be sure,
it seems foolish for the Hibernate developers to put something like
this in a library's POM, since it would seem to impose their kludge
on the programmer using the library.

Of course, we fixed our particular problem by adding an <exclusion>
for commons-logging from our hibernate-ehcache dependency.

-- Lucas

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

[Rusty Wright-2]

This may be a dumb or inappropriate question, but why does Tomcat need commons logging?  Why can't it just use java util logging?


Jörg Schaible wrote:

> Hi Ceki,
>
> Ceki Gulcu wrote at Dienstag, 30. Juni 2009 16:45:
>
>>
>> Jörg Schaible wrote:
>>
>>> You've been right, I should have read your question closer. See Dennis'
>>> answer. Actually there was an attempt to release an official empty
>>> commons-logging at Apache recently and it was tunred down exactly because
>>> we could foresee this problem you're facing now :-/
>> Note that we wanted to release version 0.0-EMPTY, not version 99. One
>> could argue that releasing 0.0-EMPTY could have prevented this issue
>> from occurring.
>
> Since the algorithm takes the distance into account, it could have been
> happened also:
>
> A depends on B, C
> B depends on D
> C depends on CL-0.0-EMPTY
> D depends on CL-1.1.1
>
> C' dep to CL-0.0-EMPTY is nearer -> compilation fails.
>
> As said, it's a good solution for an end application, but not for libraries
> used by others ;-)
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

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

[Jörg Schaible-2]

Rusty Wright wrote at Mittwoch, 1. Juli 2009 00:15:

> This may be a dumb or inappropriate question, but why does Tomcat need
> commons logging?  Why can't it just use java util logging?

Who did mention Tomcat in this thread? And no, recent versions of Tomcat use
their own logging framework JULI which is based on JUL.

- Jörg


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

[Jörg Schaible-2]

Lucas Bergman wrote at Dienstag, 30. Juni 2009 21:49:

> Dennis Lundberg wrote:
>> Lucas Bergman wrote:
>> > Running this test with Maven 2.1.0 fails:
>> >
>> >   java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
>> >   [ ... ]
>> >
>> > The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
>> > (compile-scope) dependency, so this seems wrong.  There seems to
>> > be some interaction between that POM and the dependent POMs.
>> > Indeed:
>> >
>> >   [ ... ]
>> >
>> >   2.  Adding an exclusion of commons-logging to the
>> >   hibernate-ehcache dependency causes the test to succeed.  I
>> >   tried this, because the hibernate-ehcache POM depends on
>> >   commons-logging version 99.0-does-not-exist, a rather famous
>> >   JBoss kludge[1].
>> >
>> > [ ... ]
>> >
>> > Footnotes:
>> > [1]
>> >

[http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html
>>
>> That is your problem. What this does is mess the dependency-tree. It
>> removes commons-logging from the dependency tree because that
>> version "99.0-..." is larger than the latest current release of
>> commons-logging.  The "99.0-..." version should *never ever* reach
>> end users. It can *only* be used by internal project.
>
> Thanks for the input.  Are you saying that the dependency of the
> hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?

It's an inappropriate solution for their problem with commons-logging.

> I'm sympathetic to that view, but I just want to be sure.  To be sure,
> it seems foolish for the Hibernate developers to put something like
> this in a library's POM, since it would seem to impose their kludge
> on the programmer using the library.

At least you should report this as a bug, since it actually breaks your
build. They should get at least aware or if.

> Of course, we fixed our particular problem by adding an <exclusion>
> for commons-logging from our hibernate-ehcache dependency.

You can declare commons-logging in a dependency management section. This
version and scope will have precedence over any transitive dep.

- Jörg


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

[Ceki Gulcu]

Lucas Bergman wrote:
> Dennis Lundberg wrote:

>> That is your problem. What this does is mess the dependency-tree. It
>> removes commons-logging from the dependency tree because that
>> version "99.0-..." is larger than the latest current release of
>> commons-logging.  The "99.0-..." version should *never ever* reach
>> end users. It can *only* be used by internal project.
>
> Thanks for the input.  Are you saying that the dependency of the
> hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
> I'm sympathetic to that view, but I just want to be sure.  To be sure,
> it seems foolish for the Hibernate developers to put something like
> this in a library's POM, since it would seem to impose their kludge
> on the programmer using the library.
>
> Of course, we fixed our particular problem by adding an <exclusion>
> for commons-logging from our hibernate-ehcache dependency.

Hello,

I was able to reproduce the dependency resolution issue with the help
of a small test project called "htmlunitbug" as supplied by Lucas
Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500".

However, I appears that commons-logging version 99 is not the culprit
as it is *not* involved in the resolution of commons-logging within
"htmlunitbug", the test application supplied by Lucas. At least, the
output of "mvn -X test" never mentions version 99. As further proof, I
have removed any references to version 99 in the pom files for
hibernate-ehcache and hibernate-parent, with the same results.


Just as importantly, the pom files for hibernate-ehcache and
hibernate-parent reference commons-logging version 99 in *scope*
*test*. Given that the test scope is not transitive, and given that
even after removing references to version 99, "htmlunitbug" still
fails, it would be premature to incriminate version 99. Something else
is afoot here.

[1] http://tinyurl.com/nfw332


> -- Lucas

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

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

[Ceki Gulcu]

I forgot to mention that my tests were conducted using Maven 2.0.9. I will redo
the tests with Maven 2.2.0.

Ceki Gulcu wrote:

>
>
> Lucas Bergman wrote:
>> Dennis Lundberg wrote:
>
>>> That is your problem. What this does is mess the dependency-tree. It
>>> removes commons-logging from the dependency tree because that
>>> version "99.0-..." is larger than the latest current release of
>>> commons-logging.  The "99.0-..." version should *never ever* reach
>>> end users. It can *only* be used by internal project.
>>
>> Thanks for the input.  Are you saying that the dependency of the
>> hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
>> I'm sympathetic to that view, but I just want to be sure.  To be sure,
>> it seems foolish for the Hibernate developers to put something like
>> this in a library's POM, since it would seem to impose their kludge
>> on the programmer using the library.
>>
>> Of course, we fixed our particular problem by adding an <exclusion>
>> for commons-logging from our hibernate-ehcache dependency.
>
> Hello,
>
> I was able to reproduce the dependency resolution issue with the help
> of a small test project called "htmlunitbug" as supplied by Lucas
> Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500".
>
> However, I appears that commons-logging version 99 is not the culprit
> as it is *not* involved in the resolution of commons-logging within
> "htmlunitbug", the test application supplied by Lucas. At least, the
> output of "mvn -X test" never mentions version 99. As further proof, I
> have removed any references to version 99 in the pom files for
> hibernate-ehcache and hibernate-parent, with the same results.
>
>
> Just as importantly, the pom files for hibernate-ehcache and
> hibernate-parent reference commons-logging version 99 in *scope*
> *test*. Given that the test scope is not transitive, and given that
> even after removing references to version 99, "htmlunitbug" still
> fails, it would be premature to incriminate version 99. Something else
> is afoot here.
>
> [1] http://tinyurl.com/nfw332
>
>
>> -- Lucas
>

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

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

[Ceki Gulcu]

Using Maven 2.2.0, the behavior remains the same as with Maven
2.0.9. Moreover, if you remove the dependency on
net.sf.ehcache:ehcache:1.6.0 from the pom file for "htmlunitbug", then
the test passes (with the original pom files for hibernate-ehcache
hibernate-parent referencing commons-logging version 99).

In summary, there is strong evidence that common-logging 99 is not the
culprit here.

Can it be that the various dependencies, some in test scope and some
in runtime scope, are confusing Maven's dependency resolution
mechanism?


Ceki Gulcu wrote:

>
>
> Lucas Bergman wrote:
>> Dennis Lundberg wrote:
>
>>> That is your problem. What this does is mess the dependency-tree. It
>>> removes commons-logging from the dependency tree because that
>>> version "99.0-..." is larger than the latest current release of
>>> commons-logging.  The "99.0-..." version should *never ever* reach
>>> end users. It can *only* be used by internal project.
>>
>> Thanks for the input.  Are you saying that the dependency of the
>> hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
>> I'm sympathetic to that view, but I just want to be sure.  To be sure,
>> it seems foolish for the Hibernate developers to put something like
>> this in a library's POM, since it would seem to impose their kludge
>> on the programmer using the library.
>>
>> Of course, we fixed our particular problem by adding an <exclusion>
>> for commons-logging from our hibernate-ehcache dependency.
>
> Hello,
>
> I was able to reproduce the dependency resolution issue with the help
> of a small test project called "htmlunitbug" as supplied by Lucas
> Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500".
>
> However, I appears that commons-logging version 99 is not the culprit
> as it is *not* involved in the resolution of commons-logging within
> "htmlunitbug", the test application supplied by Lucas. At least, the
> output of "mvn -X test" never mentions version 99. As further proof, I
> have removed any references to version 99 in the pom files for
> hibernate-ehcache and hibernate-parent, with the same results.
>
>
> Just as importantly, the pom files for hibernate-ehcache and
> hibernate-parent reference commons-logging version 99 in *scope*
> *test*. Given that the test scope is not transitive, and given that
> even after removing references to version 99, "htmlunitbug" still
> fails, it would be premature to incriminate version 99. Something else
> is afoot here.
>
> [1] http://tinyurl.com/nfw332
>
>
>> -- Lucas
>

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

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

[mihobson]

2009/7/1 Ceki Gulcu <ceki@...>:

> Using Maven 2.2.0, the behavior remains the same as with Maven
> 2.0.9. Moreover, if you remove the dependency on
> net.sf.ehcache:ehcache:1.6.0 from the pom file for "htmlunitbug", then
> the test passes (with the original pom files for hibernate-ehcache
> hibernate-parent referencing commons-logging version 99).
>
> In summary, there is strong evidence that common-logging 99 is not the
> culprit here.
>
> Can it be that the various dependencies, some in test scope and some
> in runtime scope, are confusing Maven's dependency resolution
> mechanism?

It has been known..

http://jira.codehaus.org/browse/MNG-4134

Have you got the dependency tree filtered for commons-logging handy?

Mark

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