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

        

Reply via email to