On Nov 2, 2006, at 10:04 AM, Prasad Kashyap wrote:
components.xml with a new lifecycle for "site"
http://people.apache.org/~prasad/components.xml
When I used to run the 'mvn -e -X site' command on the test-deployment
pom (packaging integration-test), it used to fail with the following
exception
[DEBUG] Error looking up lifecycle mapping to retrieve optional mojos.
Lifecycle ID: site. Error: Component descriptor cannot be found in the
component repository:
org.apache.maven.lifecycle.mapping.LifecycleMappingintegration-test.
org.codehaus.plexus.component.repository.exception.ComponentLookupExce
ption:
Component descriptor cannot be found in the component repository:
org.apache.maven.lifecycle.mapping.LifecycleMappingintegration-test.
Seems like the plugin extensions of the tools-plugin isn't being
recognised for "site".
I would say this is yet another bug in Maven, related to the site
life-cycle muck.
Then I added the build extension in the test-deployment pom and the
above exception disappeared !
Today, I have begun to get the following stacktrace for the same pom -
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
(Caused by org.apache.commons.logging.LogConfigurationException:
Invalid class loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.apache.geronimo.genesis.logging.Logging.reset(Logging.java:53)
at org.apache.geronimo.genesis.MojoSupport.execute
(MojoSupport.java:142)
This exception goes away if I remove the build extension.
The version of JCL which is being used is very, very picky if more
than one version of JCL is included in the classpath. Many plugins
use JCL, and when you add an extension to the Maven core which also
includes a JCL dependency, then strange problems like you see above
are bound to happen.
Did something change in genesis logging recently ? Are there any
changes I should make to fix this ?
I did clean up some logging, but short of dropping use of JCL there
is no easy fix.
We could however define a new plugin with no dependencies just to
hold the custom packaging lifecycle components... which could be
added as an extension w/o incurring this JCL problem.
--jason
