[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 ] Gleb Frank updated MCOMPILER-157: - Attachment: maven-compiler-plugin-addToSourcePathAsWell.patch For that matter, why not also add the generated sources directory to the sourcepath as well, so that it gets compiled in the same run? The attached patch (maven-compiler-plugin-addToSourcePathAsWell.patch) builds on the original one to do that. 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 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] (MEAR-147) wrong DOCTPYE in jboss-app.xml for 4.2
[
https://jira.codehaus.org/browse/MEAR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MEAR-147:
-
Fix Version/s: 2.8
wrong DOCTPYE in jboss-app.xml for 4.2
--
Key: MEAR-147
URL: https://jira.codehaus.org/browse/MEAR-147
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Andreas Wurzer
Assignee: Stephane Nicoll
Fix For: 2.8
Attachments: jboss42.patch, jboss42.patch
MEAR-104 doesn't completly fix the issue with the generated jboss-app.xml
because the PUBLIC identifier in the DOCTYPE for JBoss 4.2 should be
-//JBoss//DTD J2EE Application 4.2//EN as seen in the jboss-app_4_2.dtd.
At present it is -//JBoss//DTD J2EE Application 1.4//EN which leads to the
following problem - because it is validated against the wrong DTD for JBoss
4.0 (jboss-app_4.0.dtd).
{{org.xml.sax.SAXParseException: The content of element type jboss-app must
match
(module-order?,security-domain?,unauthenticated-principal?,loader-repository?,jmx-name?,module*,security-role*)}}
--
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] (MEAR-147) wrong DOCTPYE in jboss-app.xml for 4.2
[
https://jira.codehaus.org/browse/MEAR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MEAR-147 started by Stephane Nicoll.
wrong DOCTPYE in jboss-app.xml for 4.2
--
Key: MEAR-147
URL: https://jira.codehaus.org/browse/MEAR-147
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Andreas Wurzer
Assignee: Stephane Nicoll
Fix For: 2.8
Attachments: jboss42.patch, jboss42.patch
MEAR-104 doesn't completly fix the issue with the generated jboss-app.xml
because the PUBLIC identifier in the DOCTYPE for JBoss 4.2 should be
-//JBoss//DTD J2EE Application 4.2//EN as seen in the jboss-app_4_2.dtd.
At present it is -//JBoss//DTD J2EE Application 1.4//EN which leads to the
following problem - because it is validated against the wrong DTD for JBoss
4.0 (jboss-app_4.0.dtd).
{{org.xml.sax.SAXParseException: The content of element type jboss-app must
match
(module-order?,security-domain?,unauthenticated-principal?,loader-repository?,jmx-name?,module*,security-role*)}}
--
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] (MEAR-147) wrong DOCTPYE in jboss-app.xml for 4.2
[
https://jira.codehaus.org/browse/MEAR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-147.
Resolution: Fixed
Fixed. Thanks for the patch!
wrong DOCTPYE in jboss-app.xml for 4.2
--
Key: MEAR-147
URL: https://jira.codehaus.org/browse/MEAR-147
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Andreas Wurzer
Assignee: Stephane Nicoll
Fix For: 2.8
Attachments: jboss42.patch, jboss42.patch
MEAR-104 doesn't completly fix the issue with the generated jboss-app.xml
because the PUBLIC identifier in the DOCTYPE for JBoss 4.2 should be
-//JBoss//DTD J2EE Application 4.2//EN as seen in the jboss-app_4_2.dtd.
At present it is -//JBoss//DTD J2EE Application 1.4//EN which leads to the
following problem - because it is validated against the wrong DTD for JBoss
4.0 (jboss-app_4.0.dtd).
{{org.xml.sax.SAXParseException: The content of element type jboss-app must
match
(module-order?,security-domain?,unauthenticated-principal?,loader-repository?,jmx-name?,module*,security-role*)}}
--
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] (SUREFIRE-745) -Dtest supports multiple test classes but not multiple test methods
[ https://jira.codehaus.org/browse/SUREFIRE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SUREFIRE-745. - Resolution: Fixed Fix Version/s: 2.13 fixed r1294568. -Dtest supports multiple test classes but not multiple test methods --- Key: SUREFIRE-745 URL: https://jira.codehaus.org/browse/SUREFIRE-745 Project: Maven Surefire Issue Type: Improvement Environment: Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500) Java version: 1.6.0_24, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_CA, platform encoding: MacRoman OS name: mac os x, version: 10.6.7, arch: x86_64, family: mac Reporter: reid holmes Assignee: Olivier Lamy Priority: Minor Fix For: 2.13 Attachments: multipleMethods.patch, multipleMethods-v2.patch, multipleMethods-v3.patch, multipleMethods-v4.patch, SUREFIRE-745.patch, SUREFIRE-745-v2.patch The -Dtest parameter is very handy for running a specific test class or test method. It also supports running multiple test classes. Unfortunately, it does not permit specifying running multiple test methods. It would be great if this were possible. The examples below are from the Apache Commons project. WORKS: Run multiple test classes: mvn test -Dtest=ImmutablePairTest,StopWatchTest WORKS: Run a specific test method: mvn test -Dtest=ImmutablePairTest#testBasic DOES NOT WORK: mvn test -Dtest=StopWatchTest#testStopWatchSimple,StopWatchTest#testStopWatchSimpleGet mvn test -Dtest=ImmutablePairTest#testBasic,StopWatchTest#testLang315 -- 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] (SUREFIRE-745) -Dtest supports multiple test classes but not multiple test methods
[ https://jira.codehaus.org/browse/SUREFIRE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292906#comment-292906 ] Olivier Lamy edited comment on SUREFIRE-745 at 2/28/12 4:50 AM: fixed r1294568. Thanks ! was (Author: olamy): fixed r1294568. -Dtest supports multiple test classes but not multiple test methods --- Key: SUREFIRE-745 URL: https://jira.codehaus.org/browse/SUREFIRE-745 Project: Maven Surefire Issue Type: Improvement Environment: Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500) Java version: 1.6.0_24, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_CA, platform encoding: MacRoman OS name: mac os x, version: 10.6.7, arch: x86_64, family: mac Reporter: reid holmes Assignee: Olivier Lamy Priority: Minor Fix For: 2.13 Attachments: multipleMethods.patch, multipleMethods-v2.patch, multipleMethods-v3.patch, multipleMethods-v4.patch, SUREFIRE-745.patch, SUREFIRE-745-v2.patch The -Dtest parameter is very handy for running a specific test class or test method. It also supports running multiple test classes. Unfortunately, it does not permit specifying running multiple test methods. It would be great if this were possible. The examples below are from the Apache Commons project. WORKS: Run multiple test classes: mvn test -Dtest=ImmutablePairTest,StopWatchTest WORKS: Run a specific test method: mvn test -Dtest=ImmutablePairTest#testBasic DOES NOT WORK: mvn test -Dtest=StopWatchTest#testStopWatchSimple,StopWatchTest#testStopWatchSimpleGet mvn test -Dtest=ImmutablePairTest#testBasic,StopWatchTest#testLang315 -- 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] (MDEPLOY-147) deploy snapshot without timestamp
Lukasz Strzelecki created MDEPLOY-147:
-
Summary: deploy snapshot without timestamp
Key: MDEPLOY-147
URL: https://jira.codehaus.org/browse/MDEPLOY-147
Project: Maven 2.x and 3.x Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.7
Environment: Maven 3.0.3
Ubuntu 11.10
Reporter: Lukasz Strzelecki
Attachments: pom.xml
I've created maven project in which I want to deploy snapshot version to
snapshot repository without timestamp.
So, in tag snapshotRepository I've declared snapshot repo like this:
{code}
distributionManagement
!-- ... --
snapshotRepository
idrepo-snapshots/id
nameSnapshots maven repository/name
url[repo snapshot url]/url
uniqueVersionfalse/uniqueVersion
/snapshotRepository
!-- ... --
/distributionManagement
{code}
What is important, I've added *uniqueVersionfalse/uniqueVersion* to force
deploy process to not add tiestamp. But after invoking goal
{code}
mvn deploy
{code}
In repo is uploded snapshot with timestamp instead of SNAPSHOT postfix
Full prepared pom.xml for testing is in attachment for 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] (SUREFIRE-846) Maven surefire plugin creates two surefire* directories in the ${project.build.directory}
Martin Todorov created SUREFIRE-846:
---
Summary: Maven surefire plugin creates two surefire* directories
in the ${project.build.directory}
Key: SUREFIRE-846
URL: https://jira.codehaus.org/browse/SUREFIRE-846
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Affects Versions: 2.12
Environment: Maven 3.0.4 ; Java 1.6.0_19 ; Linux 2.6.36.2
Reporter: Martin Todorov
Hi,
This is somewhere between a bug and a feature. I am filing it as per krosenv's
suggestion.
The Maven surefire plugin is creating two surefire* directories in the
${project.build.directory}:
- surefire (empty after test executions)
- surefire-reports (containing the output of the tests)
I find this rather annoying. As far as I understand, the surefire directory is
used during the testing and it contains some temporary stuff which is removed
after the execution of the tests.
I have tried looking up the option to remove the surefire directory, but I can
seem to find it. The thing is -- I have other projects that don't have this
empty directory, just the surefire-reports.
This empty directory breaks tab autocomplete in the console which sort of bugs
me, mainly since the directory is empty.
In addition, this is just the test plugin, not the reporting one. There is no
section in the project (not any parent).
This is my surefire plugin setup:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.12/version
configuration
excludes
exclude**/*Abstr*Test*/exclude
/excludes
/configuration
/plugin
{code}
If this directory is really necessary, I would like to propose the following
options:
1) Make surefire use one directory:
{code}
- surefire
| |- reports
| |- tmp
{code}
This way things will be tidy.
2) Have an option for the plugin which allows you to turn on the preserving of
this directory (I think it should be removed by default).
Regards,
Martin
--
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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Ziesemer updated SUREFIRE-844: --- Attachment: SUREFIRE-844.zip Minimal test project demonstrating issue. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292923#comment-292923 ] Mark Ziesemer edited comment on SUREFIRE-844 at 2/28/12 10:33 AM: -- Debug output from mvn clean test on the attached test project, after only changing the Surefire plugin version from 2.12 to 2.11. Observe that 1 test executed as expected. was (Author: ziesemer): Debug output from mvn clean test on the attached test project, after changing the Surefire plugin version from 2.12 to 2.11. Observe that 1 test executed as expected. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Ziesemer updated SUREFIRE-844: --- Attachment: SUREFIRE-844-2.11.txt Debug output from mvn clean test on the attached test project, after changing the Surefire plugin version from 2.12 to 2.11. Observe that 1 test executed as expected. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Ziesemer updated SUREFIRE-844: --- Attachment: SUREFIRE-844-2.12.txt Debug output from mvn clean test on the attached test project, using Surefire plugin version 2.12 as attached. Observe the No tests were executed! exception. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292924#comment-292924 ] Mark Ziesemer edited comment on SUREFIRE-844 at 2/28/12 10:34 AM: -- SUREFIRE-844-2.12.txt: Debug output from mvn clean test on the attached test project, using Surefire plugin version 2.12 as attached. Observe the No tests were executed! exception. was (Author: ziesemer): Debug output from mvn clean test on the attached test project, using Surefire plugin version 2.12 as attached. Observe the No tests were executed! exception. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292922#comment-292922 ] Mark Ziesemer edited comment on SUREFIRE-844 at 2/28/12 10:33 AM: -- SUREFIRE-844.zip: Minimal test project demonstrating issue. was (Author: ziesemer): Minimal test project demonstrating issue. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (SUREFIRE-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292923#comment-292923 ] Mark Ziesemer edited comment on SUREFIRE-844 at 2/28/12 10:34 AM: -- SUREFIRE-844-2.11.txt: Debug output from mvn clean test on the attached test project, after only changing the Surefire plugin version from 2.12 to 2.11. Observe that 1 test executed as expected. was (Author: ziesemer): Debug output from mvn clean test on the attached test project, after only changing the Surefire plugin version from 2.12 to 2.11. Observe that 1 test executed as expected. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (MEAR-148) In an ear which has skinny wars, want to include the same jar in shared lib of ear as well as in the war
[
https://jira.codehaus.org/browse/MEAR-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MNG-5254 to MEAR-148:
--
Complexity: (was: Intermediate)
Component/s: (was: Plugins and Lifecycle)
Affects Version/s: (was: 3.0.2)
2.7
Key: MEAR-148 (was: MNG-5254)
Project: Maven 2.x Ear Plugin (was: Maven 2 3)
In an ear which has skinny wars, want to include the same jar in shared lib
of ear as well as in the war
Key: MEAR-148
URL: https://jira.codehaus.org/browse/MEAR-148
Project: Maven 2.x Ear Plugin
Issue Type: New Feature
Affects Versions: 2.7
Reporter: Tejas Pajai
I have the following artifacts
MyWar1.war depends on MyJar.jar and SomeThirdParty.jar
MyWar2.war depends on MyJar.jar
MyJar.jar also depends on SomeThirdParty.jar
Now I want to create an ear with MyWar1 and MyWar2, and I want to make them
skinny wars so that MyJar.jar should not be included in both the wars.
For some reason, the SomeThirdParty.jar has to be in the WEB-INF/lib
directory of MyWar1.war
Here is the structure I want:
{noformat}
MyEar.ear
- lib
- MyJar.jar
- SomeThirdParty.jar
- MyWar1.war
- WEB-INF/lib/SomeThirdParty.jar
- MyWar1.war
{noformat}
*As you can see, I want the SomeThirdParty.jar in MyWar1 as well as in the
lib directory.*
*Is there any way to achieve it if I am using skinnyWarstrue/skinnyWars?*
If not, we should have some way of doing this, maybe by supporting nested
dependencies in the webmodule tag which would override the skinnyWars
behavior for the listed dependencies like
{noformat}
webModule
groupIdmy.groupId/groupId
artifactIdmy.artifactId/artifactId
dependencies
dependency
groupIdSomeThirdParty.jar.groupId/groupId
artifactIdSomeThirdParty.jar/artifactId
versionSomeThirdParty.jar.version/version
/dependency
/dependencies
/webModule
{noformat}
--
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-4505) use slf4j to control various logging frameworks
[
https://jira.codehaus.org/browse/MNG-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292928#comment-292928
]
Baron Roberts commented on MNG-4505:
From my mailing list post:
{quote}
I'd like to replace the default Maven logger implementation with my own. I
assume I need to
create an extension but if that is try, how do I get a list of mojo's to call
setLog on? Is
there a Plexus injection way to do this.
Ultimately what I am trying to accomplish is interpose on the log output to
filter out messages
that are not relevant or cannot be suppressed using other means.
{quote}
use slf4j to control various logging frameworks
---
Key: MNG-4505
URL: https://jira.codehaus.org/browse/MNG-4505
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Reporter: Brett Porter
Fix For: Issues to be reviewed for 3.x
In MNG-1725, Jason indicated this was the plan for Maven 3.x. I didn't see an
existing issue and from what I can tell it hasn't been implemented yet, so
creating an issue to track it.
--
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-329) Parameter descriptions are incomplete
[ https://jira.codehaus.org/browse/MRELEASE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-329. --- Resolution: Fixed Fix Version/s: 2.2.3 Assignee: Robert Scholte Fixed in [rev. 1294741|http://svn.apache.org/viewvc?rev=1294741view=rev] Most of these parameters already retrieved their description, some have become a component or readonly and have disappeared from the documentation because of this. Parameter descriptions are incomplete - Key: MRELEASE-329 URL: https://jira.codehaus.org/browse/MRELEASE-329 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0-beta-7 Environment: http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html and the other goal descriptions Reporter: SebbASF Assignee: Robert Scholte Fix For: 2.2.3 Some optional parameters don't have defaults. In a few cases that is reasonable (e.g. optional arguments to a function), but in others it is not. For example, the following optional parameters don't have documented defaults, but should have: release:branch * branchName * password * pomFileName * providerImplementations * releaseManager * scmManager * tag * tagBase (this is implied by the text, but should be shown as a default) * username Also, it would be helpful to give examples of some of the above: what is a valid providerImplementations entry? Likewise releaseManager, scmManager? -- 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-333) allowTimestampedSnapshots is not applied to report plugins
[
https://jira.codehaus.org/browse/MRELEASE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-333.
---
Resolution: Incomplete
No feedback from user, closing it as {{incomplete}}.
allowTimestampedSnapshots is not applied to report plugins
--
Key: MRELEASE-333
URL: https://jira.codehaus.org/browse/MRELEASE-333
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-7
Environment: Any
Reporter: Kalle Korhonen
Attachments: pom.xml
Related to already resolved MRELEASE-124. allowTimestampedSnapshots make it
possible to force a release with uniquely versioned snapshots as
dependencies, but the parameter has no effect on report snapshots
dependencies. Looking at the code in the patch it seems the parameter is only
applied to straight-up project dependencies. If you are forced to use reports
that are only available as snapshots (currently e.g. the dashboard plugin),
you are out of luck unless you deploy custom versions of the plugin in your
internal repository or disable the reports for the release.
--
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-310) ForkedMavenExecutor assumes mvn is on command-line path
[ https://jira.codehaus.org/browse/MRELEASE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-310. --- Resolution: Duplicate Duplicate of MRELEASE-428, which was already fixed in version 2.0-beta-8 ForkedMavenExecutor assumes mvn is on command-line path --- Key: MRELEASE-310 URL: https://jira.codehaus.org/browse/MRELEASE-310 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare, stage Affects Versions: 2.0-beta-7 Reporter: Brian Jackson Attachments: ForkedMavenExecutor.patch The ForkedMavenExecutor assumes the mvn executable is on the command-line path. This will cause the release goals to fail if mvn is run from an explicit path and the PATH environment variable has not be set to contain a mvn executable. More dangerously though is the case where the release goal is started with an explicit mvn executable of one version (for instance 2.0.8) but a different version of the mvn executable is available on the PATH. The forked processes will run a different version of Maven2 that the parent process. -- 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-294) Generated release-pom.xml does not contain plugins configured in a super pom.
[
https://jira.codehaus.org/browse/MRELEASE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-294:
Component/s: (was: prepare)
prepare-with-pom
Generated release-pom.xml does not contain plugins configured in a super pom.
-
Key: MRELEASE-294
URL: https://jira.codehaus.org/browse/MRELEASE-294
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare-with-pom
Affects Versions: 2.0-beta-6
Reporter: Reinhard Nägele
Attachments: patch.txt
Finally, since 2.0-beta-6 it has been possible to generate release poms.
Unfortunately, plugins configured in a super pom don't make it into the
{{release-pom.xml}}.
We have a multi-module project. Each module inherits from a super pom that
also defines the modules. The super pom, amongst others, configures the
compiler plugin for {{source}} and {{target 1.5}}. Since these plugin
configurations only make it into the release pom of the super pom, but not
into the release poms of the modules, the modules fail to build using the
release plugin.
{{generics are not supported in -source 1.3 (try -source 1.5 to enable
generics)}}
{{annotations are not supported in -source 1.3 (try -source 1.5 to enable
annotations) @Override}}
So, we still have to set {{generateReleasePoms}} to {{false}}.
--
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-287) release:prepare does not change the version of parent snapshot
[ https://jira.codehaus.org/browse/MRELEASE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-287. --- Resolution: Duplicate Duplicate of MRELEASE-317, which was already fixed with version 2.1 release:prepare does not change the version of parent snapshot -- Key: MRELEASE-287 URL: https://jira.codehaus.org/browse/MRELEASE-287 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Reporter: Jean-Philippe Steck Attachments: AbstractRewritePomsPhase.java, AbstractRewritePomsPhase-resolve-parent-snapshot.patch, release-labo.zip In a project pom.xml, when the parent version is a snapshot : for example : parent groupIdgroupId/groupId artifactIdartifcatId/artifactId version0.1-SNAPSHOT/version /parent Running mvn release:prepare prompt for 'groupId:artifactId set to release? (yes/no) yes: : What is the next development version? (0.2-SNAPSHOT) 0.2-SNAPSHOT: : But then it's still 0.1-SNAPSHOT in the release and in the new developpement version. I expected the release version to be : parent groupIdgroupId/groupId artifactIdartifcatId/artifactId version0.1/version /parent and the new developpement version : parent groupIdgroupId/groupId artifactIdartifcatId/artifactId version0.2-SNAPSHOT/version /parent I attached an exemple. Thanks for any feedback on this. JP -- 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] (MWAR-277) New version does not work with yuicompressor-maven-plugin. v2.0.2 works.
Eric Miller created MWAR-277:
Summary: New version does not work with
yuicompressor-maven-plugin. v2.0.2 works.
Key: MWAR-277
URL: https://jira.codehaus.org/browse/MWAR-277
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: OSX
Reporter: Eric Miller
We use YUI Compressor to minify static web resources. With nosuffix on, this
produces a .js or .css file of the same name in the target dir (eg:
src/main/webapp/script.js becomes target/script.js). This is a good way to work
because then your script and style references don't need to change between
development and qa or dev int (wherever you test minified resources).
The problem is that v2.1.1 overwrites files in the target dir if they already
exist. v2.0.2 did not behave in this way.
There must have been some change in the way that overwriting existing files
behaves, but I cannot find a flag to switch that behavior back.
We have reverted to the old version of the war plugin for now.
our config:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0.2/version
!-- version2.1.1/version breaks YUI compressor --
configuration
useDefaultManifestFiletrue/useDefaultManifestFile
archive
manifestEntries
Implementation-Title${project.name}/Implementation-Title !-- This is in
the default manifest, but we add it explicitly so m2e-wtp
can pick it up --
Implementation-Version${project.version}/Implementation-Version !-- This
is in the default manifest, but we add it explicitly so m2e-wtp
can pick it up --
ReleaseName${releasename}/ReleaseName
/manifestEntries
/archive
/configuration
/plugin
{code}
--
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-400) Failed to validate POM for project ... at ...\release-pom.xml
[
https://jira.codehaus.org/browse/MRELEASE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-400:
Component/s: (was: prepare)
prepare-with-pom
Failed to validate POM for project ... at ...\release-pom.xml
-
Key: MRELEASE-400
URL: https://jira.codehaus.org/browse/MRELEASE-400
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare-with-pom
Reporter: Borut Bolcina
When releasing the multimodule project and one of the transitive dependencies
is tools.jar a fatal error occurs.
mvn release:prepare -DgenerateReleasePoms=true
...
[INFO] Executing: mvn clean verify --no-plugin-updates -P proxy
[INFO] Scanning for projects...
[INFO] NOTE: Using release-pom:
C:\eclipse\workspace\trident-project\release-pom.xml in reactor build.
[INFO] NOTE: Using release-pom:
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml in reactor
build.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: com.interseek:trident-admin
POM Location:
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
Validation Messages:
[0] For dependency Dependency {groupId=com.sun, artifactId=tools,
version=1.5.0, type=jar}: system-scoped dependency must specify systemPath.
Reason: Failed to validate POM for project
com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate
POM for project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException:
Failed to validate POM for project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at
org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Wed Oct 08 11:14:22 CEST 2008
[INFO] Final Memory: 1M/2M
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Maven execution failed, exit code: '1'
[INFO]
[jira] (MRELEASE-400) Failed to validate POM for project ... at ...\release-pom.xml
[
https://jira.codehaus.org/browse/MRELEASE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-400:
Description:
When releasing the multimodule project and one of the transitive dependencies
is tools.jar a fatal error occurs.
{{mvn release:prepare -DgenerateReleasePoms=true}}
{noformat}
...
[INFO] Executing: mvn clean verify --no-plugin-updates -P proxy
[INFO] Scanning for projects...
[INFO] NOTE: Using release-pom:
C:\eclipse\workspace\trident-project\release-pom.xml in reactor build.
[INFO] NOTE: Using release-pom:
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml in reactor
build.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: com.interseek:trident-admin
POM Location:
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
Validation Messages:
[0] For dependency Dependency {groupId=com.sun, artifactId=tools,
version=1.5.0, type=jar}: system-scoped dependency must specify systemPath.
Reason: Failed to validate POM for project com.interseek:trident-admin
at C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate
POM for project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException:
Failed to validate POM for project com.interseek:trident-admin at
C:\eclipse\workspace\trident-project\trident-admin\release-pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at
org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Wed Oct 08 11:14:22 CEST 2008
[INFO] Final Memory: 1M/2M
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Maven execution failed, exit code: '1'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 57 seconds
[INFO] Finished at: Wed Oct 08 11:14:22 CEST 2008
[INFO] Final Memory: 8M/14M
[INFO]
{noformat}
The 3rd party pom has this in the POM:
{code:xml}
profiles
profile
iddefault-tools.jar/id
activation
property
[jira] (MDEPLOY-147) deploy snapshot without timestamp
[
https://jira.codehaus.org/browse/MDEPLOY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-147.
--
Resolution: Not A Bug
See the [Combatibility Notes|
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments]
for Maven3
deploy snapshot without timestamp
-
Key: MDEPLOY-147
URL: https://jira.codehaus.org/browse/MDEPLOY-147
Project: Maven 2.x and 3.x Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.7
Environment: Maven 3.0.3
Ubuntu 11.10
Reporter: Lukasz Strzelecki
Attachments: pom.xml
I've created maven project in which I want to deploy snapshot version to
snapshot repository without timestamp.
So, in tag snapshotRepository I've declared snapshot repo like this:
{code}
distributionManagement
!-- ... --
snapshotRepository
idrepo-snapshots/id
nameSnapshots maven repository/name
url[repo snapshot url]/url
uniqueVersionfalse/uniqueVersion
/snapshotRepository
!-- ... --
/distributionManagement
{code}
What is important, I've added *uniqueVersionfalse/uniqueVersion* to force
deploy process to not add tiestamp. But after invoking goal
{code}
mvn deploy
{code}
In repo is uploded snapshot with timestamp instead of SNAPSHOT postfix
Full prepared pom.xml for testing is in attachment for 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] (MRELEASE-634) Versions of snapshot dependencies to the same artifact with different classifiers are not updated correctly during release:prepare
[
https://jira.codehaus.org/browse/MRELEASE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-634.
---
Resolution: Duplicate
Duplicate of MRELEASE-161
Versions of snapshot dependencies to the same artifact with different
classifiers are not updated correctly during release:prepare
---
Key: MRELEASE-634
URL: https://jira.codehaus.org/browse/MRELEASE-634
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.1
Reporter: Steffi Tinder
Attachments: continue-after-rewriting.patch
If you have several dependencies to the same artifact with different
classifiers, the versions are not correctly updated by the release-plugin.
Consider the following scenario:
You have the following two dependencies in your pom:
{code:xml}
dependency
groupIdgroupid/groupId
artifactIdartifactid/artifactId
version1.0-SNAPSHOT/version
/dependency
dependency
groupIdgroupid/groupId
artifactIdartifactid/artifactId
scopetest/scope
classifiertests/classifier
version1.0-SNAPSHOT/version
/dependency
{code}
During release:prepare, the plugin will ask you to enter release and dev
version for groupid:artifact twice, but it will discard the information you
entered the first time.
This happens because the ReleaseManager uses a versionlessKey to store the
resolved snapshot dependencies.
{code:title=org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase}
private Map processSnapshot( Set snapshotSet )
throws PrompterException, VersionParseException
{
...
resolvedSnapshots.put( versionlessKey, versionMap );
...
}
{code}
When the version tags in the pom are updated with the new versions, only one
of the dependencies will be updated. Again, the release-plugin will only use
groupid and artifactid to identify the dependency.
It also checks if the dependency was already updated and so the second
dependency-element is ignored:
{code:title=org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase}
private void rewriteDependencies( List dependencies, Element dependencyRoot,
Map mappedVersions,
Map resolvedSnapshotDependencies, Map
originalVersions, String projectId,
Element properties, ReleaseResult
result, ReleaseDescriptor releaseDescriptor )
throws ReleaseExecutionException, ReleaseFailureException
{
...
if ( !dependenciesAlreadyChanged.contains( depId ) )
{
//This check is required because updateDomVersion update all
dependencies with the current groupId/artifactId
//(standard dependencies and sub-dependencies like ejb-client) so we
don't need to re-update them
...
}
}
{code}
*Summary:*
The problem consists of two parts:
1. the version information entered for the second dependency is discarded
(that means you couldn't specify different versions for the two dependencies)
2. only on of the dependency elements is updated during the release
The result is a remaining SNAPSHOT-dependency in the released artifacts.
--
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-265) Make pom writable on prepare
[ https://jira.codehaus.org/browse/MRELEASE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292953#comment-292953 ] Robert Scholte commented on MRELEASE-265: - Why is the POM readonly? Make pom writable on prepare Key: MRELEASE-265 URL: https://jira.codehaus.org/browse/MRELEASE-265 Project: Maven 2.x Release Plugin Issue Type: Wish Components: prepare Affects Versions: 2.0-beta-6 Environment: Any Reporter: Jon Strayer Priority: Minor If release:prepare fails for me it normally fails because the POM is read only. Why not do automatically what I have to do manually (make the POM writable)? -- 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-663) Null error when project is too close to root
[ https://jira.codehaus.org/browse/MRELEASE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292955#comment-292955 ] Robert Scholte commented on MRELEASE-663: - Could you specify the version of the maven-release-plugin? Is it still a problem with the current version(2.2.2)? Null error when project is too close to root Key: MRELEASE-663 URL: https://jira.codehaus.org/browse/MRELEASE-663 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Environment: Maven 2.2.1, Windows XP SP3 Reporter: Brent Smith Priority: Minor Co-worker ran into issues where if he had checked out his project directly in his root dir C:\ (top pom ending up in C:\project\pom.xml) and ran the release:prepare goal he would rather quickly recieve this error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.shared.release.util.ReleaseUtil.getBaseWorkingDirect oryParentCount(ReleaseUtil.java:233) at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran slateScm(RewritePomsForReleasePhase.java:109) at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran sformScm(RewritePomsForReleasePhase.java:62) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf ormDocument(AbstractRewritePomsPhase.java:303) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf ormProject(AbstractRewritePomsPhase.java:208) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf orm(AbstractRewritePomsPhase.java:114) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execut e(AbstractRewritePomsPhase.java:97) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default ReleaseManager.java:203) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default ReleaseManager.java:140) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default ReleaseManager.java:103) at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr epareReleaseMojo.java:211) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRe leaseMojo.java:181) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) I looked into it and eventually had him add a buffer directory so his top pom was resting in C:\workspace\project\pom.xml and following this move it built properly. Not sure if there is a real requirement to have this buffer directory, but a better error message would be helpful. -- 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] (ARCHETYPE-401) use repo.maven.apache.org CNAME or repo to provide more stability
Herve Boutemy created ARCHETYPE-401: --- Summary: use repo.maven.apache.org CNAME or repo to provide more stability Key: ARCHETYPE-401 URL: https://jira.codehaus.org/browse/ARCHETYPE-401 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.2 Reporter: Herve Boutemy like it was done in Maven 3.0.4: see MNG-5151 -- 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] (ARCHETYPE-401) use repo.maven.apache.org CNAME or repo to provide more stability
[ https://jira.codehaus.org/browse/ARCHETYPE-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-401. --- Resolution: Fixed Fix Version/s: 2.3 Assignee: Herve Boutemy done in [r1294863|http://svn.apache.org/viewvc?rev=1294863] use repo.maven.apache.org CNAME or repo to provide more stability - Key: ARCHETYPE-401 URL: https://jira.codehaus.org/browse/ARCHETYPE-401 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.2 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 2.3 like it was done in Maven 3.0.4: see MNG-5151 -- 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] (ARCHETYPE-401) use repo.maven.apache.org CNAME to provide more stability
[ https://jira.codehaus.org/browse/ARCHETYPE-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-401: Summary: use repo.maven.apache.org CNAME to provide more stability (was: use repo.maven.apache.org CNAME or repo to provide more stability) use repo.maven.apache.org CNAME to provide more stability - Key: ARCHETYPE-401 URL: https://jira.codehaus.org/browse/ARCHETYPE-401 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.2 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 2.3 like it was done in Maven 3.0.4: see MNG-5151 -- 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] (MRRESOURCES-58) 'process' goal fails with NPE at the root of a reactor if child modules use version ranges for dependencies
[ https://jira.codehaus.org/browse/MRRESOURCES-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ivanov updated MRRESOURCES-58: - Attachment: version-ranges-bugfix-v2.patch Actually, on the second thought, filtering is only performed when excludeTransitive is set to true (the default value is false). Which means that we can place the whole block, including the filter, into a conditional statement, and avoid unnecessary work in 99% of current use cases. Please see the 2nd patch to that effect. 'process' goal fails with NPE at the root of a reactor if child modules use version ranges for dependencies --- Key: MRRESOURCES-58 URL: https://jira.codehaus.org/browse/MRRESOURCES-58 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.2.1, 1.3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) Java version: 1.6.0_25, vendor: Sun Microsystems Inc. Default locale: en_GB, platform encoding: UTF-8 OS name: windows xp, version: 5.1, arch: x86, family: windows Reporter: Sergei Ivanov Attachments: test-reactor-version-ranges.zip, version-ranges-bugfix.patch, version-ranges-bugfix-v2.patch When the maven-remote-resources-plugin:process goal is integrated into the lifecycle of a parent project in a multi-module reactor build, the goal fails with an NPE if dependency version ranges are used in the child modules. Additionally, runOnlyAtExecutionRoot option needs to be set to true in order to recreate the problem. Please see the attached test project that demonstrates the problem. Full exception trace is as follows: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process (process-remote-resources) on project test-parent: Execution process-remote-resources of goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process (process-remote-resources) on project test-parent: Execution process-remote-resources of goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) at org.codehaus.classworlds.Launcher.main(Launcher.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution process-remote-resources of goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. at
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
Bart Skondin created MNG-5255: - Summary: Dependency with 'provided' scope has its transitive dependency included in final artifact Key: MNG-5255 URL: https://jira.codehaus.org/browse/MNG-5255 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) Maven home: D:\bin\apache-maven-3.0.4 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: D:\bin\java\jdk1.6.0_27\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Bart Skondin Attachments: provided-scope-not-working.zip Expected: A dependency declared with a scope of 'provided', along with any transitive dependencies, should not be included in the final artifact. Actual: I have a dependency, jsp-api, declared with 'provided' scope. This dependency has a dependency of its own, servlet-api. The servlet-api.jar is being included in the web-inf/lib folder of the resultant war file. Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem was not witnessed until after the upgrade. Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib folder. Notice that the servlet-api.jar has been included. Additional Info: It seems that I can only reproduce this behavior when declaring a specific dependency in my pom, spring-ldap. Here is the dependency tree for the given pared-down project (attached): --- maven-dependency-plugin:2.1:tree (default-cli) @ provided-scope-not-working --- com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT +- javax.servlet:jsp-api:jar:2.0:provided | \- javax.servlet:servlet-api:jar:2.4:provided \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile +- commons-logging:commons-logging:jar:1.0.4:compile +- commons-lang:commons-lang:jar:2.1:compile +- org.springframework:spring-beans:jar:2.0.6:compile | +- (commons-logging:commons-logging:jar:1.1:compile - omitted for conflict with 1.0.4) | \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for duplicate) \- org.springframework:spring-core:jar:2.0.6:compile \- (commons-logging:commons-logging:jar:1.1:compile - omitted for conflict with 1.0.4) -- 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] (MASSEMBLY-601) http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html seems to have the components of a filter element in the wrong order
Benson Margulies created MASSEMBLY-601: -- Summary: http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html seems to have the components of a filter element in the wrong order Key: MASSEMBLY-601 URL: https://jira.codehaus.org/browse/MASSEMBLY-601 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Benson Margulies The page says: or they may be fully qualified in the form groupId:artifactId:type:version[:classifier] However, it seems by experiment that the order is: groupId:artifactId:type:classifier:version I'd just fix it but I was hoping that someone would tell me that I haven't lost my mind. -- 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] (SUREFIRE-745) -Dtest supports multiple test classes but not multiple test methods
[ https://jira.codehaus.org/browse/SUREFIRE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292966#comment-292966 ] rainLee commented on SUREFIRE-745: -- my pleasure:-) -Dtest supports multiple test classes but not multiple test methods --- Key: SUREFIRE-745 URL: https://jira.codehaus.org/browse/SUREFIRE-745 Project: Maven Surefire Issue Type: Improvement Environment: Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500) Java version: 1.6.0_24, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_CA, platform encoding: MacRoman OS name: mac os x, version: 10.6.7, arch: x86_64, family: mac Reporter: reid holmes Assignee: Olivier Lamy Priority: Minor Fix For: 2.13 Attachments: multipleMethods.patch, multipleMethods-v2.patch, multipleMethods-v3.patch, multipleMethods-v4.patch, SUREFIRE-745.patch, SUREFIRE-745-v2.patch The -Dtest parameter is very handy for running a specific test class or test method. It also supports running multiple test classes. Unfortunately, it does not permit specifying running multiple test methods. It would be great if this were possible. The examples below are from the Apache Commons project. WORKS: Run multiple test classes: mvn test -Dtest=ImmutablePairTest,StopWatchTest WORKS: Run a specific test method: mvn test -Dtest=ImmutablePairTest#testBasic DOES NOT WORK: mvn test -Dtest=StopWatchTest#testStopWatchSimple,StopWatchTest#testStopWatchSimpleGet mvn test -Dtest=ImmutablePairTest#testBasic,StopWatchTest#testLang315 -- 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] (MASSEMBLY-578) lineEnding parameter makes assembly ignore empty directories
[
https://jira.codehaus.org/browse/MASSEMBLY-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292972#comment-292972
]
Ed Hillmann commented on MASSEMBLY-578:
---
I can confirm this occurs when using a type of dir as well. I'm using Maven
3.0.3, and the 2.3 version of the assembly plugin.
Empty (sub) directories are retained if no lineEndings are specified, but lost
if lineEndings are defined for the fileset.
lineEnding parameter makes assembly ignore empty directories
Key: MASSEMBLY-578
URL: https://jira.codehaus.org/browse/MASSEMBLY-578
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Windows 7 Enterprise x64 sp1
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_25
Reporter: Elie Delorme
Attachments: assembly.xml, pom.xml
Empty directories are ignored if the lineEnding parameter is used in a
fileset.
Created archive will contain empty directories if I either remove the
lineEnding parameter OR remove any text file from the directory structure.
structure:
{noformat}
pom.xml
src/main/assembly/assembly.xml
src/main/include/a/test.txt
/b/
{noformat}
pom.xml
{noformat}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
version0-SNAPSHOT/version
packagingpom/packaging
nametest/name
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
appendAssemblyIdfalse/appendAssemblyId
attachfalse/attach
descriptors
descriptorsrc/main/assembly/assembly.xml/descriptor
/descriptors
/configuration
/plugin
/plugins
/build
/project
{noformat}
assembly.xml
{noformat}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
iddistribution/id
formats
formattar.gz/format
/formats
fileSets
fileSet
directorysrc/main/include/directory
outputDirectory//outputDirectory
lineEndingunix/lineEnding
/fileSet
/fileSets
/assembly
{noformat}
*test*
{noformat}
mvn clean assembly:single
set MAVEN_OPTS=-Xmx256m
[INFO] Scanning for projects...
[INFO]
[INFO] Building test
[INFO]task-segment: [clean, assembly:single]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory C:\ATM\emptybug\trunk\target
[INFO] [assembly:single {execution: default-cli}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO] Building tar : C:\ATM\emptybug\trunk\target\test-0-SNAPSHOT.tar.gz
[WARNING] Assembly file: C:\ATM\emptybug\trunk\target\test-0-SNAPSHOT.tar.gz
is not a regular file (
it may be a directory). It cannot be attached to the project build for
installation or deployment.
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Oct 06 09:06:23 EDT 2011
[INFO] Final Memory: 8M/162M
[INFO]
bsdtar ztvf target\test-0-SNAPSHOT.tar.gz
drwxr-xr-x 0 0 0 0 Oct 06 09:06 test-0-SNAPSHOT/
drwxr-xr-x 0 0 0 0 Oct 06 09:06 test-0-SNAPSHOT/a/
-rw-r--r-- 0 0 0 0 Oct 06 09:06 test-0-SNAPSHOT/a/test.txt
{noformat}
*without lineEnding*
--
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] (MASSEMBLY-578) lineEnding parameter makes assembly ignore empty directories
[
https://jira.codehaus.org/browse/MASSEMBLY-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292972#comment-292972
]
Ed Hillmann edited comment on MASSEMBLY-578 at 2/28/12 11:38 PM:
-
I can confirm this occurs when using a format of dir as well. I'm using
Maven 3.0.3, and the 2.3 version of the assembly plugin.
Empty (sub) directories are retained if no lineEndings are specified, but lost
if lineEndings are defined for the fileset.
was (Author: hildo):
I can confirm this occurs when using a type of dir as well. I'm using
Maven 3.0.3, and the 2.3 version of the assembly plugin.
Empty (sub) directories are retained if no lineEndings are specified, but lost
if lineEndings are defined for the fileset.
lineEnding parameter makes assembly ignore empty directories
Key: MASSEMBLY-578
URL: https://jira.codehaus.org/browse/MASSEMBLY-578
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Windows 7 Enterprise x64 sp1
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_25
Reporter: Elie Delorme
Attachments: assembly.xml, pom.xml
Empty directories are ignored if the lineEnding parameter is used in a
fileset.
Created archive will contain empty directories if I either remove the
lineEnding parameter OR remove any text file from the directory structure.
structure:
{noformat}
pom.xml
src/main/assembly/assembly.xml
src/main/include/a/test.txt
/b/
{noformat}
pom.xml
{noformat}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
version0-SNAPSHOT/version
packagingpom/packaging
nametest/name
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
appendAssemblyIdfalse/appendAssemblyId
attachfalse/attach
descriptors
descriptorsrc/main/assembly/assembly.xml/descriptor
/descriptors
/configuration
/plugin
/plugins
/build
/project
{noformat}
assembly.xml
{noformat}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
iddistribution/id
formats
formattar.gz/format
/formats
fileSets
fileSet
directorysrc/main/include/directory
outputDirectory//outputDirectory
lineEndingunix/lineEnding
/fileSet
/fileSets
/assembly
{noformat}
*test*
{noformat}
mvn clean assembly:single
set MAVEN_OPTS=-Xmx256m
[INFO] Scanning for projects...
[INFO]
[INFO] Building test
[INFO]task-segment: [clean, assembly:single]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory C:\ATM\emptybug\trunk\target
[INFO] [assembly:single {execution: default-cli}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO] Building tar : C:\ATM\emptybug\trunk\target\test-0-SNAPSHOT.tar.gz
[WARNING] Assembly file: C:\ATM\emptybug\trunk\target\test-0-SNAPSHOT.tar.gz
is not a regular file (
it may be a directory). It cannot be attached to the project build for
installation or deployment.
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Oct 06 09:06:23 EDT 2011
[INFO] Final Memory: 8M/162M
[INFO]
bsdtar ztvf target\test-0-SNAPSHOT.tar.gz
drwxr-xr-x 0 0 0 0 Oct 06 09:06 test-0-SNAPSHOT/
drwxr-xr-x 0 0 0 0 Oct 06 09:06 test-0-SNAPSHOT/a/
-rw-r--r-- 0 0 0 0 Oct 06 09:06 test-0-SNAPSHOT/a/test.txt
{noformat}
*without lineEnding*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
