[jira] Updated: (MRELEASE-286) Classpath errors during release:perform

["Arnaud Heritier (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arnaud Heritier updated MRELEASE-286:
-------------------------------------

    Component/s: prepare

> 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
>          Components: prepare
>    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