You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Cameron Jones (JIRA)" <ji...@codehaus.org> on 2007/09/17 21:46:11 UTC
[jira] Created: (MRELEASE-286) Classpath errors during
release:perform
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
[jira] Updated: (MRELEASE-286) Classpath errors during
release:perform
Posted by "Cameron Jones (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Updated: (MRELEASE-286) Classpath errors during
release:perform
Posted by "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
[jira] Commented: (MRELEASE-286) Classpath errors during
release:perform
Posted by "Cameron Jones (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107596 ]
Cameron Jones commented on MRELEASE-286:
----------------------------------------
This could be related to MRELEASE-140
> 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
[jira] Updated: (MRELEASE-286) Classpath errors during
release:perform
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Lundberg updated MRELEASE-286:
-------------------------------------
Component/s: (was: prepare)
perform
> 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: perform
> 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
[jira] (MRELEASE-286) Classpath errors during release:perform
Posted by "Robert Scholte (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] (MRELEASE-286) Classpath errors during release:perform
Posted by "Robert Scholte (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Scholte updated MRELEASE-286:
------------------------------------
Priority: Major (was: Blocker)
Assignee: Robert Scholte
Lowering priority to major, with version 2.3 the perform succeeds even though I still see the errors.
> 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