You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by ji...@codehaus.org on 2004/09/10 18:09:11 UTC

[jira] Created: (MPTEST-42) test fails when project depends on commons-logging-api

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/browse/MPTEST-42

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: MPTEST-42
    Summary: test fails when project depends on commons-logging-api
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: maven-test-plugin

   Assignee: 
   Reporter: Duffy Gillman

    Created: Fri, 10 Sep 2004 12:08 PM
    Updated: Fri, 10 Sep 2004 12:08 PM

Description:
If a project has a dependency on commons-logging-api tests will fail because either maven, or the test plugin are already using a version of commons-logging-api.

For example, project.xml contains:

	<dependency>
		<groupId>commons-logging</groupId>
		<artifactId>commons-logging-api</artifactId>
		<version>1.0.4</version>
	</dependency>

Running 'maven test' produces the following in the test-reports output file:

java.lang.ExceptionInInitializerError
        at JUnitTestCaseSubclass.testMethod(JUnitTestCaseSubclass.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
...
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log'
visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version
of 'org.apache.commons.logging.Log' visible, which is not allowed.))
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
        at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
...


This call to LogFactory.getLog(...) occurs within the code under test.

In order to get around this, the project must be compiled with the dependency in the project.xml file.  Then 'maven test' must be run with the dependency commented out.

A property within the dependency to ignore the dependency during test would be helpful.  Otherwise, logic that detects the version conflict and excises the commons-logging-api.jar from the classpath during test, would be helpful.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MPTEST-42) test fails when project depends on commons-logging-api

Posted by ji...@codehaus.org.
The following comment has been added to this issue:

     Author: David Eric Pugh
    Created: Fri, 10 Sep 2004 12:19 PM
       Body:
Take a looksee at how junit dependency is used in the test..  You may want to see about submitting a patch that works similar for commons-logging...
---------------------------------------------------------------------
View this comment:
  http://jira.codehaus.org/browse/MPTEST-42?page=comments#action_23966

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/browse/MPTEST-42

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: MPTEST-42
    Summary: test fails when project depends on commons-logging-api
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: maven-test-plugin

   Assignee: 
   Reporter: Duffy Gillman

    Created: Fri, 10 Sep 2004 12:08 PM
    Updated: Fri, 10 Sep 2004 12:19 PM

Description:
If a project has a dependency on commons-logging-api tests will fail because either maven, or the test plugin are already using a version of commons-logging-api.

For example, project.xml contains:

	<dependency>
		<groupId>commons-logging</groupId>
		<artifactId>commons-logging-api</artifactId>
		<version>1.0.4</version>
	</dependency>

Running 'maven test' produces the following in the test-reports output file:

java.lang.ExceptionInInitializerError
        at JUnitTestCaseSubclass.testMethod(JUnitTestCaseSubclass.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
...
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log'
visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version
of 'org.apache.commons.logging.Log' visible, which is not allowed.))
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
        at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
...


This call to LogFactory.getLog(...) occurs within the code under test.

In order to get around this, the project must be compiled with the dependency in the project.xml file.  Then 'maven test' must be run with the dependency commented out.

A property within the dependency to ignore the dependency during test would be helpful.  Otherwise, logic that detects the version conflict and excises the commons-logging-api.jar from the classpath during test, would be helpful.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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