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 sy
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 t
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
explicitl
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
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
[IN
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:
name="org.openejb.deployment.UnpackedModuleDeploymentTest">
messag
On 9/12/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
FYI, I have seen some strange JCL related problems with GShell... and
I ended up excluding any JCL dependencies that were picked up
transitively and upgrading to JCL 1.1 to get logging happy again.
Ah, you're right - the transitive dependencie
FYI, I have seen some strange JCL related problems with GShell... and
I ended up excluding any JCL dependencies that were picked up
transitively and upgrading to JCL 1.1 to get logging happy again.
--jason
On Sep 11, 2006, at 3:39 PM, Jacek Laskowski wrote:
On 9/12/06, David Jencks <[EMAI
On 9/12/06, David Jencks <[EMAIL PROTECTED]> wrote:
I sometimes get this error building openejb-core:
java.lang.NoSuchMethodError:
org.apache.commons.logging.LogFactory.release(Ljava/lang/ClassLoader;)V
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
(MultiP
I sometimes get this error building openejb-core:
name="org.openejb.deployment.UnpackedModuleDeploymentTest">
message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
ClassLoader;)V">java.lang.NoSuchMethodError:
org.apache.commons.logging.LogFactory.release(Ljava/lang/ClassLoad
10 matches
Mail list logo