geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <a_kuls...@yahoo.com>
Subject Re: Another really strange mysterious build error
Date Wed, 13 Sep 2006 15:30:27 GMT
    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 <kevan.miller@gmail.com> 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 <jason@planet57.com> 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 

Mime
View raw message