Classpath errors during release:perform
---------------------------------------
Key: MRELEASE-286
URL: http://jira.codehaus.org/browse/MRELEASE-286
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Cameron Jones
Priority: Blocker
Attachments: sandbox-release-console.log, sandbox-release-perform.log,
sandbox-release-prepare.log, sandbox.zip
I have a standard web app project which consists of a core module, a web app
and some web services. In the project build i have some automated tasks setup
to create the client stub classes by starting a jetty web container, deploying
the web app, and then hitting the web service to access the generated wsdl so
it can create a stub library. This process works during a standard 'install'
goal and when running the 'release:prepare' goal, however when running
'release:perform' i encounter some library conflicts which i can only guess are
as a result of a polluted class path.
The specific error i get is that there is more than 1 commons-logging library
on the classpath. I know this is a common error but i have it sucessfully
working in the other goals and i've spent a lot of time making sure it's not an
actual commons-logging issue. Also, i've also seen
java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a
result of running the same config.
Is there anything special about the way that the release:perform task manages
it's classpath? I notice that the perform task actually executes several
iterations of build during this phase, is it possible that the previous
iterations classpath is not isolated?
To illustrate the issue i've created a test project which mimics the
functionality in my app and illustrates the issue. I've attached the project to
this jira and also the logs files from running release:prepare and
release:perform. Unfortunately the error in jetty is output to the console so
i've got that as a separate file.
The test project has the following modules:
pom.xml - Parent POM
core/pom.xml - Core POM using commons-logging with no concrete loggers packaged
or as transitive dependencies
web/pom.xml - Web App using commons loggins also with no concrete log
implementation (log4j is added explicity just for unit tests)
test/pom.xml - Client stub generation module (sorry should have renamed to
something better).
The client stub module starts jetty using cargo during the initialize phase and
deploy the web app. In the real app it would generate the stub classes but in
this example it just needs to depoy the app for the error to occur. During the
compile phase it shuts down jetty.
To test i'm afraid you'll have to create a subversion repo for the app but that
should be pretty much it. You might need to reconfigue where the site is deploy
to as well. The only external property config should be the scm connection
details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
