The problem did go away after excluding commons-logging from
axion.
However there are 2 issues:
1. The path to dependency in '[INFO] Failed to resolve artifact'
message is wrong. I have seen wrong path before also.
2. Maven is supposed to pull in all the transitive dependencies unless
explicitly excluded. Maven2 seems to be treating commons-logging
differently than the other jars. In an earlier encounter I had faced a
similar problem:
http://www.nabble.com/Re%3A-Questions-about-the-packaging-plugin-
p3936387.html
Here is an excerpt from today's debug output:
[DEBUG] axion:axion:jar:1.0-M3-dev:test (selected for test)
[DEBUG] commons-logging:commons-logging:jar:1.0:test (setting
scope
to: compile)
[DEBUG] commons-collections:commons-collections:jar:3.0:test
(selected for test)
[DEBUG] commons-primitives:commons-primitives:jar:1.0:test
(selected for test)
[DEBUG] commons-codec:commons-codec:jar:1.2:test (selected for
test)
[DEBUG] While downloading javacc:javacc:3.2
This artifact has been relocated to net.java.dev.javacc:javacc:3.2.
[DEBUG] net.java.dev.javacc:javacc:jar:3.2:test (selected for
test)
Axion is a dependency in openejb-builder with 'test' scope. Maven
sets all its dependencies as test scope. But commons-logging is set to
compile! Does any one know why it should be like this.
Thanks
Anita
--- Kevan Miller <[EMAIL PROTECTED]> wrote:
I believe this problem was fixed last night by jason and david j with
an OpenEJB change to trunk/openejb2/pom.xml. The change excludes a
transitive dependency for commons-logging being pulled in for axion.
IIUC, maven/surefire was actively pulling in transitive dependencies
(unless excluded). In this case, when the itest was being run the
axion dependency on the old version of commons-logging was taking
precedence.
This seems like a pretty fragile environment -- this class loading
behavior could mask problems that might exist in a true server
environment, or (as we saw here) generate unique itest problems.
Jason/David, do I have this right? How do we resolve these issues in
the future?
--kevan
On Sep 13, 2006, at 12:43 AM, anita kulshreshtha wrote:
As Jacek pointed out it is because of commons-logging jar with a
version prior to 1.0.3. It appears that one of the source of this
jar
is geronimo-kernel! how is that possible?
thanks
Anita
[INFO]
----------------------------------------------------------------------
--
[ERROR] BUILD ERROR
[INFO]
----------------------------------------------------------------------
--
[INFO] Failed to resolve artifact.
Missing:
----------
1) commons-logging:commons-logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=commons-logging
-DartifactId=commons-lo
gging \
-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT
2)
org.apache.geronimo.modules:geronimo-axis-builder:jar:1.2-SNAPSHOT
3) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-
SNAPSHOT
4) commons-logging:commons-logging:jar:1.0
--- Jason Dillon <[EMAIL PROTECTED]> wrote:
I see this too... have not looked into it, but we need to fix
this,
its causing bootstrap builds of G to fail.
--jason
On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
I sometimes get this error building openejb-core:
<testcase time="1.273"
name="org.openejb.deployment.UnpackedModuleDeploymentTest">
<error type="java.lang.NoSuchMethodError"
message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
ClassLoader;)V">java.lang.NoSuchMethodError:
org.apache.commons.logging.LogFactory.release(Ljava/lang/
ClassLoader;)V
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
(MultiParentClassLoader.java:386)
at
org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
(JarFileClassLoader.java:147)
at
org.apache.geronimo.kernel.config.Configuration.shutdown
(Configuration.java:762)
at org.apache.geronimo.kernel.config.Configuration.doStop
(Configuration.java:742)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
(SimpleConfigurationManager.java:718)
at
org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
(DeploymentConfigurationManager.java:161)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
figuration(SimpleConfigurationManager.java:698)
at
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
nfiguration(DeploymentConfigurationManager.java:157)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
figuration(SimpleConfigurationManager.java:668)
at
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
nfiguration(DeploymentConfigurationManager.java:153)
at org.apache.geronimo.deployment.DeploymentContext.close
(DeploymentContext.java:364)
at org.openejb.deployment.DeploymentTestSuite.setUp
(DeploymentTestSuite.java:201)
at org.openejb.deployment.DeploymentTestSuite.access$000
(DeploymentTestSuite.java:90)
at org.openejb.deployment.DeploymentTestSuite$1.protect
(DeploymentTestSuite.java:119)
at
junit.framework.TestResult.runProtected(TestResult.java:
124)
at org.openejb.deployment.DeploymentTestSuite.run
(DeploymentTestSuite.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.maven.surefire.junit.JUnitTestSet.execute
(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
Set(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:122)
at
org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:225)
at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:747)
</error>
</testcase>
I can't quite imagine how this can occur. Can anyone else?
Anyway putting a try/catch block around the code to ignore the
error at least lets the test pass. Should I commit this or can
anyone think of a possible cause so we can actually fix it?
thanks
david jencks
__________________________________________________
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
