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 <[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.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
