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
