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:03:04 GMT
AFAIK, the only was to completely isolate ourselves from these issues  
going forward is to have complete control over the dependencies used  
in the build.  That means, only our repo, only artifacts which we  
have blessed to be used, known good pom's...  and then version  
control/notification system when artifacts change so that we can  
track down when something breaks.

You are absolutely right though... this is a very fragile  
environment... and I will even go on to say that Maven breeds  
fragility in larger more complicated projects.

--jason


On Sep 13, 2006, at 6:53 AM, Kevan Miller 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.unloadCo 
>> n
>>>
>>>> figuration(SimpleConfigurationManager.java:698)
>>>>         at
>>>>
>>>
>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadC 
>> o
>>>
>>>> nfiguration(DeploymentConfigurationManager.java:157)
>>>>         at
>>>>
>>>
>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCo 
>> n
>>>
>>>> figuration(SimpleConfigurationManager.java:668)
>>>>         at
>>>>
>>>
>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadC 
>> o
>>>
>>>> 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.executeTes 
>> t
>>>
>>>> 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
>>>>
>>>
>>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>


Mime
View raw message