You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (JIRA)" <ji...@codehaus.org> on 2014/11/25 21:23:31 UTC

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

     [ https://jira.codehaus.org/browse/MPTEST-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Osipov closed MPTEST-42.
--------------------------------

    Resolution: Won't Fix

Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

> test fails when project depends on commons-logging-api
> ------------------------------------------------------
>
>                 Key: MPTEST-42
>                 URL: https://jira.codehaus.org/browse/MPTEST-42
>             Project: Maven 1.x Test Plugin
>          Issue Type: Bug
>            Reporter: Duffy Gillman
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)