geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Another really strange mysterious build error
Date Wed, 13 Sep 2006 20:05:16 GMT
Maven is not treating commons-logging differently... Maven just gets  
easily confused when there are multiple versions of artifacts with  
the same ids, some included some excluded.

I ran into this very problem, where it looked like special attention  
was being given to commons-logging... and the solution I found was to  
exclude all commons-logging 1.0.x and use commons-logging-api and  
commons-logging-adapters from the new JCL 1.1

--jason


On Sep 13, 2006, at 8:30 AM, anita kulshreshtha wrote:

>     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