[jira] (SCM-674) ScmFile.path should always be relative and never start with any file-separator
[ https://jira.codehaus.org/browse/SCM-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299103#comment-299103 ] Mark Struberg commented on SCM-674: --- Be careful with this one. There might be tons of side effects waiting for you. Most of the SCMs do NOT take a relative file:// url but only absolute ones. Thus you would really make an absolute file out of it most times. > ScmFile.path should always be relative and never start with any > file-separator > --- > > Key: SCM-674 > URL: https://jira.codehaus.org/browse/SCM-674 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.7 >Reporter: Robert Scholte >Priority: Minor > > With these restrictions we have better control over the ScmFiles, so projects > using SCM don't have to write their own workarounds. -- 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] (MPMD-147) Migrate to PMD 5.0.0
Andreas Dangel created MPMD-147: --- Summary: Migrate to PMD 5.0.0 Key: MPMD-147 URL: https://jira.codehaus.org/browse/MPMD-147 Project: Maven 2.x PMD Plugin Issue Type: New Feature Components: PMD Affects Versions: 2.8 Reporter: Andreas Dangel Attachments: 0001-Migrate-to-PMD-5.0.0.patch PMD recently released the new version 5.0.0. It would be great to upgrade the maven-pmd-plugin to this new version. I've created a patch and attached it to this issue. -- 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] (MPMD-147) Migrate to PMD 5.0.0
[ https://jira.codehaus.org/browse/MPMD-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299134#comment-299134 ] Andreas Dangel commented on MPMD-147: - Note: Also I didn't add any new test cases, I've adjusted the existing test cases slightly. > Migrate to PMD 5.0.0 > > > Key: MPMD-147 > URL: https://jira.codehaus.org/browse/MPMD-147 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: PMD >Affects Versions: 2.8 >Reporter: Andreas Dangel > Attachments: 0001-Migrate-to-PMD-5.0.0.patch > > > PMD recently released the new version 5.0.0. It would be great to upgrade the > maven-pmd-plugin to this new version. > I've created a patch and attached it to this issue. -- 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] (MPMD-148) Add support for javascript / ecmascript
Andreas Dangel created MPMD-148: --- Summary: Add support for javascript / ecmascript Key: MPMD-148 URL: https://jira.codehaus.org/browse/MPMD-148 Project: Maven 2.x PMD Plugin Issue Type: New Feature Components: PMD Affects Versions: 2.8 Reporter: Andreas Dangel Attachments: 0001-Add-support-for-javascript-ecmascript.patch With the new version 5.0.0 of PMD it is possible to analyze other languages, e.g. javascript. This patch adds support to the maven-pmd-plugin. Note: This patch depends upon MPMD-147 -- 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] (MPMD-147) Migrate to PMD 5.0.0
[ https://jira.codehaus.org/browse/MPMD-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299134#comment-299134 ] Andreas Dangel edited comment on MPMD-147 at 5/18/12 7:36 AM: -- Note: Although I didn't add any new test cases, I've adjusted the existing test cases slightly. was (Author: adangel): Note: Also I didn't add any new test cases, I've adjusted the existing test cases slightly. > Migrate to PMD 5.0.0 > > > Key: MPMD-147 > URL: https://jira.codehaus.org/browse/MPMD-147 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: PMD >Affects Versions: 2.8 >Reporter: Andreas Dangel > Attachments: 0001-Migrate-to-PMD-5.0.0.patch > > > PMD recently released the new version 5.0.0. It would be great to upgrade the > maven-pmd-plugin to this new version. > I've created a patch and attached it to this issue. -- 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] (MPMD-146) An incomplete fix for the resource leak bugs in CpdReport.java
[
https://jira.codehaus.org/browse/MPMD-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-146:
Attachment: 0001-Close-the-fileoutputstream-in-the-finally-block-too..patch
Simple fix - closes the file output stream in the finally block, too.
> An incomplete fix for the resource leak bugs in CpdReport.java
> --
>
> Key: MPMD-146
> URL: https://jira.codehaus.org/browse/MPMD-146
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.8
>Reporter: Guangtai Liang
>Priority: Critical
> Attachments:
> 0001-Close-the-fileoutputstream-in-the-finally-block-too..patch
>
>
> The fix revision 730089 was aimed to remove an resource leak bug on the
> OutputStreamWriter object "writer" (created in line 188) in the method
> "writeNonHtml()" of the file
> "/maven/plugins/trunk/maven-pmd-plugin/src/main/java/org/apache/maven/plugin/pmd/CpdReport.java"
> ,
> but it is incomplete.
> There are some problems:
> 1. when "writer" is not created successfully at line 189 but the
> FileOutputStream object "tStream" is created successfully at line
> 188,"tStream" will be leaked.
> The best way to close such resource objects is putting such close operations
> for all resource objects in the finaly block of a try-catch-finally structure.
> Although a later fix (rev935316) tried to fix it, the problem still exists in
> the head revision. The buggy code is copied as bellows (the object "tStream"
> needs to be closed at line 220):
> void writeNonHtml( CPD cpd )
> throws MavenReportException
> {
> Renderer r = createRenderer();
> if ( r == null )
> {
> return;
> }
> String buffer = r.render( cpd.getMatches() );
> Writer writer = null;
> try
> {
> targetDirectory.mkdirs();
> File targetFile = new File( targetDirectory, "cpd." + format );
> 220FileOutputStream tStream = new FileOutputStream( targetFile );
> 221writer = new OutputStreamWriter( tStream, getOutputEncoding()
> );
> writer.write( buffer );
> writer.close();
> File siteDir = getReportOutputDirectory();
> siteDir.mkdirs();
> FileUtils.copyFile( targetFile, new File( siteDir, "cpd." +
> format ) );
> }
> catch ( IOException ioe )
> {
> throw new MavenReportException( ioe.getMessage(), ioe );
> }
> finally
> {
> 235IOUtil.close( writer );
> }
> }
--
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] (MPMD-144) An incomplete fix for the resource leak bugs in PmdReport.java
[
https://jira.codehaus.org/browse/MPMD-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-144:
Attachment: 0001-Close-the-fileoutputstream-in-the-finally-block-too..patch
> An incomplete fix for the resource leak bugs in PmdReport.java
> --
>
> Key: MPMD-144
> URL: https://jira.codehaus.org/browse/MPMD-144
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.8
>Reporter: Guangtai Liang
>Priority: Critical
> Attachments:
> 0001-Close-the-fileoutputstream-in-the-finally-block-too..patch
>
>
> The fix revision 935344 was aimed to remove an resource leak bug on the
> OutputStreamWriter object "writer" (created in line 323) in the method
> "execute()" of the file
> "/maven/plugins/trunk/maven-pmd-plugin/src/main/java/org/apache/maven/plugin/pmd/PmdReport.java"
> , but it is incomplete.
> There are some problems:
> 1. when "writer" is not created successfully but the FileOutputStream object
> "tStream" is created successfully at line 322,"tStream" will be leaked.
> The best way to close such resource objects is putting such close operations
> in the finaly block of a try-catch-finally structure.
> The problem still exists in the head revision. The buggy code is copied as
> bellows:
>try
> {
> targetDirectory.mkdirs();
> File targetFile = new File( targetDirectory, "pmd." + format );
> 357FileOutputStream tStream = new FileOutputStream( targetFile );
> 358writer = new OutputStreamWriter( tStream, getOutputEncoding()
> );
> r.setWriter( writer );
> r.start();
> r.renderFileReport( report );
> r.end();
> writer.close();
> File siteDir = getReportOutputDirectory();
> siteDir.mkdirs();
> FileUtils.copyFile( targetFile, new File( siteDir, "pmd." +
> format ) );
> }
> catch ( IOException ioe )
> {
> throw new MavenReportException( ioe.getMessage(), ioe );
> }
> finally
> {
> 376 IOUtil.close( writer );
> }
--
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] (MPMD-145) An incomplete fix for the resource leak bugs in PmdReportTest.java
[
https://jira.codehaus.org/browse/MPMD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-145:
Attachment: 0001-Close-the-readers-in-a-finally-block-MPMD-145.patch
> An incomplete fix for the resource leak bugs in PmdReportTest.java
> --
>
> Key: MPMD-145
> URL: https://jira.codehaus.org/browse/MPMD-145
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.8
>Reporter: Guangtai Liang
>Priority: Critical
> Attachments: 0001-Close-the-readers-in-a-finally-block-MPMD-145.patch
>
>
> The fix revision 729532 was aimed to remove an resource leak bug on the
> BufferedReader object "in" (created in line 240) in the method "readFile()"
> of the file "/maven/plugins/trunk/maven-pmd-
> plugin/src/test/java/org/apache/maven/plugin/pmd/PmdReportTest.java" , but it
> is incomplete.
> There are some problems:
> 1. when "in" is not created successfully but the temp FileReader object is
> created successfully at line 240,the temp FileReader object will be leaked.
> The best way to close such resource objects is putting such close operations
> in the finaly block of a try-catch-finally structure.
> The problem still exists in the head revision. The buggy code is copied as
> bellows:
> private String readFile( File file )
> throws IOException
> {
> String strTmp;
> StringBuffer str = new StringBuffer( (int) file.length() );
> 246BufferedReader in = new BufferedReader( new FileReader( file ) );
> while ( ( strTmp = in.readLine() ) != null )
> {
> str.append( ' ' );
> str.append( strTmp );
> }
> 253in.close();
> return str.toString();
> }
--
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] (SCM-674) ScmFile.path should always be relative and never start with any file-separator
[
https://jira.codehaus.org/browse/SCM-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299147#comment-299147
]
Robert Scholte commented on SCM-674:
In that case we need to add a property. We can leave {{path}} for the SCM
internals and add for instance relativePath which should be used by projects
depending on SCM. Sounds better?
> ScmFile.path should always be relative and never start with any
> file-separator
> ---
>
> Key: SCM-674
> URL: https://jira.codehaus.org/browse/SCM-674
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-api
>Affects Versions: 1.7
>Reporter: Robert Scholte
>Priority: Minor
>
> With these restrictions we have better control over the ScmFiles, so projects
> using SCM don't have to write their own workarounds.
--
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] (MNG-2258) Wrong execution order of plugins in same phase
[ https://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299149#comment-299149 ] Scott Glajch commented on MNG-2258: --- I'm not sure if this warrants reopening this bug or a new bug (or hopefully I'm missing something and just doing it wrong), but I think a slightly more complicated version of this use case is failing for us. We are using 3.0.3, and in general, the ordering of plugins with the same lifecycle phase is consistent to the order they were declared in the pom. However it appears that once we add another plugin execution for the same plugin type and the same lifecycle in a parent pom, the ordering gets screwed up. Our pom has 3 plugins executing during the "prepare-package" lifecycle currently. They are (in order of declaration in the pom): maven-war-plugin:2.2.rsa3:exploded (default) maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (perform xslt transformation) Just like they, they execute in the correct order. Then, in the parent pom for our projects we added this to the "prepare-package" lifecycle: gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) Now when our project runs, the plugins get executed in this order: maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) gmaven-plugin:1.3:execute (perform xslt transformation) I don't know if the fourth goal (the war plugin goal) ever gets executed because the build fails during "perform xslt transformation" because it is relying on the war goal to run first. I would hazard a guess that the problem has to do with either inserting plugin executions from a parent project, or the combination of that and the fact that the same plugin was defined in both the current and parent project. The ordering logic might never have taken this into account because you're not allowed to define the same plugin twice within the same pom file. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: https://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benson Margulies >Priority: Blocker > Fix For: 3.0.3 > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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] (MNG-2258) Wrong execution order of plugins in same phase
[ https://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299149#comment-299149 ] Scott Glajch edited comment on MNG-2258 at 5/18/12 9:55 AM: I'm not sure if this warrants reopening this bug or a new bug (or hopefully I'm missing something and just doing it wrong), but I think a slightly more complicated version of this use case is failing for us. We are using 3.0.3 and in general, the ordering of plugins with the same lifecycle phase is consistent to the order they were declared in the pom. However it appears that once we add another plugin execution for the same plugin type and the same lifecycle in a parent pom, the ordering gets screwed up. Our pom has 3 plugins executing during the "prepare-package" lifecycle currently. They are (in order of declaration in the pom): maven-war-plugin:2.2.rsa3:exploded (default) maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (perform xslt transformation) They execute in the correct order. Then, in the parent pom for our projects we added this to the "prepare-package" lifecycle: gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) Now when our project runs, the plugins get executed in this order: maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) gmaven-plugin:1.3:execute (perform xslt transformation) I don't know if the fourth goal (the war plugin goal) ever gets executed because the build fails during "perform xslt transformation" because it is relying on the war goal to run first. I would hazard a guess that the problem has to do with either inserting plugin executions from a parent project, or the combination of that and the fact that the same plugin was defined in both the current and parent project. The ordering logic might never have taken this into account because you're not allowed to define the same plugin twice within the same pom file. was (Author: glajchs): I'm not sure if this warrants reopening this bug or a new bug (or hopefully I'm missing something and just doing it wrong), but I think a slightly more complicated version of this use case is failing for us. We are using 3.0.3, and in general, the ordering of plugins with the same lifecycle phase is consistent to the order they were declared in the pom. However it appears that once we add another plugin execution for the same plugin type and the same lifecycle in a parent pom, the ordering gets screwed up. Our pom has 3 plugins executing during the "prepare-package" lifecycle currently. They are (in order of declaration in the pom): maven-war-plugin:2.2.rsa3:exploded (default) maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (perform xslt transformation) Just like they, they execute in the correct order. Then, in the parent pom for our projects we added this to the "prepare-package" lifecycle: gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) Now when our project runs, the plugins get executed in this order: maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) gmaven-plugin:1.3:execute (perform xslt transformation) I don't know if the fourth goal (the war plugin goal) ever gets executed because the build fails during "perform xslt transformation" because it is relying on the war goal to run first. I would hazard a guess that the problem has to do with either inserting plugin executions from a parent project, or the combination of that and the fact that the same plugin was defined in both the current and parent project. The ordering logic might never have taken this into account because you're not allowed to define the same plugin twice within the same pom file. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: https://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benson Margulies >Priority: Blocker > Fix For: 3.0.3 > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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 mo
[jira] (MRELEASE-286) Classpath errors during release:perform
[ 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
[jira] (MRELEASE-286) Classpath errors during release:perform
[
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 r
[jira] (MCOMPILER-157) Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files
[ https://jira.codehaus.org/browse/MCOMPILER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCOMPILER-157: --- Fix Version/s: 2.5 > Maven Compiler Plugin should add to compileSourceRoots for next plugins to > consider as source directory for generated files > > > Key: MCOMPILER-157 > URL: https://jira.codehaus.org/browse/MCOMPILER-157 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.3.2 > Environment: Java 6 >Reporter: Zoran Regvart > Fix For: 2.5 > > Attachments: maven-compiler-plugin-add-compileSourceRoots.patch, > maven-compiler-plugin-addToSourcePathAsWell.patch, TestCase2.zip, > test-case.zip > > > Maven Compiler Plugin by relying on javac by default, on Java 6 platform > includes annotation processors in it's processing, these in end could > generate sources that are placed by default in > target/generated-sources/annotations. The later should be added to > compileSourceRoots so that next plugin in execution would consider those > sources. > Please, see the attached test case and consider the attached patch in the > next release of maven-compiler-plugin. > thanks, > Zoran -- 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-726) mvn release:prepare-with-pom not honouring the commitByProject parameter.
[
https://jira.codehaus.org/browse/MRELEASE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-726:
Description:
Using this in my pom file:
{code:xml}
org.apache.maven.plugins
maven-release-plugin
2.2.2
deploy
false
true
true
{code}
Running this command:
{{mvn release:prepare}}
Correctly goes into each directory to make changes, e.g.
{noformat}
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add -- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git status
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git commit
--verbose -F /tmp/maven-scm-561169862.commit pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git add
-- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
status
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
commit --verbose -F /tmp/maven-scm-2018482909.commit pom.xml
{noformat}
etc ...
However running this command:
{{mvn release:prepare-with-pom}}
So that I can generate a release-pom.xml file errors because it attempts to do
all the checkins on one line:
{noformat}
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add --
release-pom.xml foundation/release-pom.xml module/release-pom.xml
module/advertising/release-pom.xml module/buttonconfig/release-pom.xml
module/core/release-pom.xml module/film/release-pom.xml
module/profile/release-pom.xml module/proxy/release-pom.xml
module/rental/release-pom.xml module/service/release-pom.xml
module/smartcard/release-pom.xml module/telephony/release-pom.xml
module/terminalui/release-pom.xml module/tv/release-pom.xml
module/upsell/release-pom.xml module/urlconfig/release-pom.xml
mule/release-pom.xml mule/advertising/release-pom.xml
mule/button-config/release-pom.xml mule/film/release-pom.xml
mule/hospediacard/release-pom.xml mule/location/release-pom.xml
mule/profile/release-pom.xml mule/proxy/release-pom.xml
mule/rental/release-pom.xml mule/service/release-pom.xml
mule/smartcard/release-pom.xml mule/startup/release-pom.xml
mule/terminaluimenu/release-pom.xml mule/tv/release-pom.xml
mule/upsell/release-pom.xml mule/urlconfig/release-pom.xml
{noformat}
This doesn't work for my setup because each directory is a git submodule so
must be run separately, it looks to me like it's simply ignoring the
{{commitByProject}} setting, but the docs
(http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html)
list it as being a supported property since {{2.0-beta5}}. I've marked this
as a blocker because I wanted to use the release-pom.xml and I have no way to
generate them now (since the {{-DgenerateReleasePoms}} option on the
{{release:prepare}} goal seems to have been deprecated).
was:
Using this in my pom file:
org.apache.maven.plugins
maven-release-plugin
2.2.2
deploy
false
true
true
Running this command:
mvn release:prepare
Correctly goes into each directory to make changes, e.g.
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add -- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git status
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git commit
--verbose -F /tmp/maven-scm-561169862.commit pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git add
-- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
status
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/founda
[jira] (MECLIPSE-722) Add support for Websphere 8.0
Amit Gadkari created MECLIPSE-722:
-
Summary: Add support for Websphere 8.0
Key: MECLIPSE-722
URL: https://jira.codehaus.org/browse/MECLIPSE-722
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: M2Eclipse support, WTP support
Affects Versions: 2.9
Reporter: Amit Gadkari
Current code in workspaceconfiguration.java needs to be modified for adding
support for websphere 8.0
Add if condition
if ( getDefaultDeployServerId().indexOf( "v8" ) >= 0 )
{
return "8.0";
}
WorkspaceConfiguration.java
* @return the defined websphere server version and null if the target is no
websphere.
*/
public String getWebsphereVersion()
{
if ( getDefaultDeployServerId() != null &&
getDefaultDeployServerId().startsWith( "was." ) )
{
if ( getDefaultDeployServerId().indexOf( "v7" ) >= 0 )
{
return "7.0";
}
if ( getDefaultDeployServerId().indexOf( "v61" ) >= 0 )
{
return "6.1";
}
if ( getDefaultDeployServerId().indexOf( "v6" ) >= 0 )
{
return "6.0";
}
if ( getDefaultDeployServerId().indexOf( "v51" ) >= 0 )
{
return "5.1";
}
if ( getDefaultDeployServerId().indexOf( "v5" ) >= 0 )
{
return "5.0";
}
}
return null;
}
--
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
