[
http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cameron Jones updated MRELEASE-286:
-----------------------------------
Attachment: sandbox-release-console.log
> 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
