[
https://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-286.
-----------------------------------
Resolution: Not A Bug
I'm closing this as 'not a bug', because it's probably the best classifier of
all options.
The short story: use the proper phases to bind the goals. Jetty should not be
part of the packaging-process but of the integration test. So you should bind
{{cargo-maven2-plugin:start}} to {{pre-integration-test}} and
{{cargo-maven2-plugin:stop}} to {{post-integration-test}} and the the
surefire-plugin to {{integration-test}} (actually I'd prefer the
failsafe-plugin, which is the surefire-plugin for integration-tests. They use
the same code!)
A workaround which should always work is to go to the
{{target/chechout}}-directory and run {{mvn deploy site-deploy}} from this
directory.
Now the longer story:
During the {{release:perform}} a release-profile is triggered, which executes
{{maven-source-plugin:2.1.2:jar}}.
This is an important rule of that goal:
{quote}Invokes the execution of the lifecycle phase generate-sources prior to
executing itself.{quote}
Since you've bind the {{cargo-maven2-plugin:start}} to {{initialize}} another
jetty-container is started. And now you'll get your error. Here's mine:
{quote}
[INFO] 2012-05-17 23:54:52.718:WARN::Can't reuse C:\Users\ROBERT~1\AppData\Local
\Temp\Jetty_0_0_0_0_8180_web.0.3.war__sandbox.web__.x2ghl6, using C:\Users\ROBER
T~1\AppData\Local\Temp\Jetty_0_0_0_0_8180_web.0.3.war__sandbox.web__.x2ghl6_8594
699344283821692
[INFO] 2012-05-17 23:54:52.721:INFO::Extract D:\temp\sandbox\target\checkout\web
\target\web-0.3.war to C:\Users\ROBERT~1\AppData\Local\Temp\Jetty_0_0_0_0_8180_w
eb.0.3.war__sandbox.web__.x2ghl6_8594699344283821692\webapp
[INFO] 2012-05-17 23:54:52.983:WARN:/sandbox-web:unavailable
[INFO] org.apache.commons.logging.LogConfigurationException: org.apache.commons.
logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationEx
ception: Invalid class loader hierarchy. You have more than one version of 'org
.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apach
e.commons.logging.LogConfigurationException: Invalid class loader hierarchy. Yo
u have more than one version of 'org.apache.commons.logging.Log' visible, which
is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException
: org.apache.commons.logging.LogConfigurationException: Invalid class loader hie
rarchy. You have more than one version of 'org.apache.commons.logging.Log' visi
ble, which is not allowed. (Caused by org.apache.commons.logging.LogConfiguratio
nException: Invalid class loader hierarchy. You have more than one version of '
org.apache.commons.logging.Log' visible, which is not allowed.))
{quote}
I don't think it's worth digging any deeper. Just use the proper phases and
this issue should be solved.
> Classpath errors during release:perform
> ---------------------------------------
>
> Key: MRELEASE-286
> URL: https://jira.codehaus.org/browse/MRELEASE-286
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
> Affects Versions: 2.0-beta-6
> Reporter: Cameron Jones
> Assignee: Robert Scholte
> 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, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
