[jira] (MCHECKSTYLE-172) Checkstyle Plugin 2.8+ generates an additional aggregate report
[
https://jira.codehaus.org/browse/MCHECKSTYLE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311938#comment-311938
]
Justin Ye commented on MCHECKSTYLE-172:
---
Is there any update on this issue? I know we have workaround for this.
But it seems this issue is blocking the release of new version 2.10
Checkstyle Plugin 2.8+ generates an additional aggregate report
---
Key: MCHECKSTYLE-172
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-172
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.8, 2.9
Environment: mvn --version
Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home:
/Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac
Reporter: SebbASF
Assignee: Dennis Lundberg
Fix For: 2.10
Using a very simple single module project, the aggregated report is created
by default.
Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.
--
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] (MSHARED-252) drop XmlReader and only use XmlStreamReader
[ https://jira.codehaus.org/browse/MSHARED-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-252. - Resolution: Fixed Fix Version/s: maven-shared-utils-0.1 drop XmlReader and only use XmlStreamReader --- Key: MSHARED-252 URL: https://jira.codehaus.org/browse/MSHARED-252 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-utils Reporter: Mark Struberg Assignee: Mark Struberg Fix For: maven-shared-utils-0.1 XmlReader is a left-over from a refactoring. Oringinally there have been a XmlWriter too. But due to build conflicts with the class XMLWriter (on windows boxes) it got renamed to XmlStreamWriter and XmlReader got duplicated. Thus we should now get rid of XmlReader and only use XmlStreamReader instead to be more consistent -- 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] (MSHARED-236) Refactor utility classes of shared components into an own utility package
[ https://jira.codehaus.org/browse/MSHARED-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-236. - Resolution: Fixed Fix Version/s: maven-shared-utils-0.1 Almost all important p-u classes are now either moved from other modules,IP clean imported by their original authors or got rewritten. Refactor utility classes of shared components into an own utility package - Key: MSHARED-236 URL: https://jira.codehaus.org/browse/MSHARED-236 Project: Maven Shared Components Issue Type: Bug Reporter: Mark Struberg Assignee: Mark Struberg Fix For: maven-shared-utils-0.1 Attachments: MSHARED-236-krosenvold-original-work.patch DirectoryScanner in maven-verifier is one example. We should introcude a new shared-utils module which doesn't contain any external dependencies if possible. -- 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-1378) Make dependencies of test-jars transitive
[ https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311946#comment-311946 ] Tony Lampada commented on MNG-1378: --- To Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/53/make-dependencies-of-test-jars-transitive and offer a few bucks for it. (Learn more -- http://blog.freedomsponsors.org/about/) Make dependencies of test-jars transitive - Key: MNG-1378 URL: https://jira.codehaus.org/browse/MNG-1378 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0 Reporter: Mark Hobson Fix For: Issues to be reviewed for 3.x Attachments: mng1378.tar.gz test-jar transitive dependencies are calculated as per compile scope rather than test scope. The situation is demonstrated nicely in it0077: * module sub1 has a test-scoped dependency of commons-lang * module sub2 has a test-scoped dependency of sub1 test-jar sub2 tests should inherit the commons-lang transitive dependency. For example: Index: maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java === --- maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (revision 328307) +++ maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (working copy) @@ -1,6 +1,7 @@ package org.apache.maven.it0077; import junit.framework.TestCase; +import org.apache.commons.lang.BooleanUtils; public class PersonTwoTest extends PersonTest Results in: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] package org.apache.commons.lang does not exist -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311947#comment-311947 ] Tony Lampada commented on MNG-624: -- Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-915) runOrder=failedfirst runs new tests last
Takeji Naigeon created SUREFIRE-915: --- Summary: runOrder=failedfirst runs new tests last Key: SUREFIRE-915 URL: https://jira.codehaus.org/browse/SUREFIRE-915 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.12.3 Reporter: Takeji Naigeon Attachments: maven_surefire-fix.patch -- 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-915) runOrder=failedfirst runs new tests last
[ https://jira.codehaus.org/browse/SUREFIRE-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311965#comment-311965 ] Takeji Naigeon commented on SUREFIRE-915: - Sorry, looks like description got lost : According to surefire:test documentation, for the runOrder parameter : Failed first will run tests that failed on previous run first, as well as new tests for this run But looks like to me that new tests are run last. Which doesn't help getting fast feedback IMHO. I joined a patch (for version 2.12.3 as it's the one we're using) with RunEntryStatisticsMapTest updated, but it's my first time looking into surefire source code, I don't know if it is the right way to fix it. TIA runOrder=failedfirst runs new tests last Key: SUREFIRE-915 URL: https://jira.codehaus.org/browse/SUREFIRE-915 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.12.3 Reporter: Takeji Naigeon Attachments: maven_surefire-fix.patch -- 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-915) runOrder=failedfirst runs new tests last
[ https://jira.codehaus.org/browse/SUREFIRE-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311965#comment-311965 ] Takeji Naigeon edited comment on SUREFIRE-915 at 10/22/12 10:30 AM: Sorry, looks like description got lost : According to surefire:test documentation, for the runOrder parameter : Failed first will run tests that failed on previous run first, as well as new tests for this run But looks like to me that new tests are run last. Which doesn't help getting fast feedback IMHO. I joined a patch (for version 2.12.3 as it's the one we're using) with RunEntryStatisticsMapTest updated, but it's my first time looking into surefire source code, I don't know if it is the right way to fix it. Thank you was (Author: tnaigeon): Sorry, looks like description got lost : According to surefire:test documentation, for the runOrder parameter : Failed first will run tests that failed on previous run first, as well as new tests for this run But looks like to me that new tests are run last. Which doesn't help getting fast feedback IMHO. I joined a patch (for version 2.12.3 as it's the one we're using) with RunEntryStatisticsMapTest updated, but it's my first time looking into surefire source code, I don't know if it is the right way to fix it. TIA runOrder=failedfirst runs new tests last Key: SUREFIRE-915 URL: https://jira.codehaus.org/browse/SUREFIRE-915 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.12.3 Reporter: Takeji Naigeon Attachments: maven_surefire-fix.patch -- 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] (MDEP-386) Split purge-local-repository into manual and transitive
Paul Gier created MDEP-386: -- Summary: Split purge-local-repository into manual and transitive Key: MDEP-386 URL: https://jira.codehaus.org/browse/MDEP-386 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Reporter: Paul Gier There doesn't seem to be a good way to resolve/purge/re-resolve from the local repository in a reliable way that works with both Maven 2 and 3. So to simplify the code for this goal, it could be split into a manual mode goal which doesn't required dependency resolution, and a transitive mode which uses the plugin configuration for the initial dependency resolution. The manual mode simply deletes a set of directories from the local repository. The automated mode first resolves to the project dependencies to get the full information about them, then purges a filtered list from the local repository, then optionally re-resolves any dependencies that were purged. -- 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] (MDEP-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-386: --- Fix Version/s: 2.6 Assignee: Paul Gier Split purge-local-repository into manual and transitive --- Key: MDEP-386 URL: https://jira.codehaus.org/browse/MDEP-386 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Reporter: Paul Gier Assignee: Paul Gier Fix For: 2.6 There doesn't seem to be a good way to resolve/purge/re-resolve from the local repository in a reliable way that works with both Maven 2 and 3. So to simplify the code for this goal, it could be split into a manual mode goal which doesn't required dependency resolution, and a transitive mode which uses the plugin configuration for the initial dependency resolution. The manual mode simply deletes a set of directories from the local repository. The automated mode first resolves to the project dependencies to get the full information about them, then purges a filtered list from the local repository, then optionally re-resolves any dependencies that were purged. -- 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] (MDEP-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-386. -- Resolution: Fixed Fixed in [r1400930|http://svn.apache.org/viewvc?view=revisionrevision=1400930] Split purge-local-repository into manual and transitive --- Key: MDEP-386 URL: https://jira.codehaus.org/browse/MDEP-386 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Reporter: Paul Gier Assignee: Paul Gier Fix For: 2.6 There doesn't seem to be a good way to resolve/purge/re-resolve from the local repository in a reliable way that works with both Maven 2 and 3. So to simplify the code for this goal, it could be split into a manual mode goal which doesn't required dependency resolution, and a transitive mode which uses the plugin configuration for the initial dependency resolution. The manual mode simply deletes a set of directories from the local repository. The automated mode first resolves to the project dependencies to get the full information about them, then purges a filtered list from the local repository, then optionally re-resolves any dependencies that were purged. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311972#comment-311972 ] Ian A. commented on MNG-624: Excellent idea! Sponsored! automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-624: - Comment: was deleted (was: Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it.) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-1378) Make dependencies of test-jars transitive
[ https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-1378: -- Comment: was deleted (was: To Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/53/make-dependencies-of-test-jars-transitive and offer a few bucks for it. (Learn more -- http://blog.freedomsponsors.org/about/)) Make dependencies of test-jars transitive - Key: MNG-1378 URL: https://jira.codehaus.org/browse/MNG-1378 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0 Reporter: Mark Hobson Fix For: Issues to be reviewed for 3.x Attachments: mng1378.tar.gz test-jar transitive dependencies are calculated as per compile scope rather than test scope. The situation is demonstrated nicely in it0077: * module sub1 has a test-scoped dependency of commons-lang * module sub2 has a test-scoped dependency of sub1 test-jar sub2 tests should inherit the commons-lang transitive dependency. For example: Index: maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java === --- maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (revision 328307) +++ maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (working copy) @@ -1,6 +1,7 @@ package org.apache.maven.it0077; import junit.framework.TestCase; +import org.apache.commons.lang.BooleanUtils; public class PersonTwoTest extends PersonTest Results in: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] package org.apache.commons.lang does not exist -- 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-5177) Maven adds tests dependecies into depgraph even when skipping tests
[ https://jira.codehaus.org/browse/MNG-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311981#comment-311981 ] John Casey commented on MNG-5177: - IMO this is a dangerous thing to add without warning. Any plugin can specify '@RequiresDependencResolution test' and get tripped up with this patch, it's not only those that respond to maven.test.skip. In fact, I can think of use cases off the top of my head (creating a standalone buildable archive of a project using the assembly plugin being one) where test scope is needed, but have nothing at all to do with compiling/executing tests directly. Maven adds tests dependecies into depgraph even when skipping tests --- Key: MNG-5177 URL: https://jira.codehaus.org/browse/MNG-5177 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Reporter: Stanislav Ochotnicky Priority: Minor Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch Maven 3.x adds test dependencies into dependency graph even when we use -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and failure of build if the repository with test dependencies is offline. I was able to solve this by patching maven in following way: 1. add new DependencySelector implementation that looks at environment variables and omits test dependencies when maven.test.skip property is found 2. modify maven-compat as well so that old code paths work the same way. Maybe a better way to do part 1 would be to modify ScopeDependencySelector, and if that's the preferred way I can rework the patch that way. I had several issues with the implementation: 1. For some reason I wasn't able to get property definition from MavenSession so I used System.getProperty directly. Any idea what might be the reason? 2. Is there perhaps a better way to figure out that tests are being skipped instead of looking for maven.test.skip property? 3. I had to copy non-test artifacts of dependencies in DefaultArtifactResolver because original implementation didn't provide remove method. Not a big deal I guess, but worth a note. -- 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-5177) Maven adds tests dependecies into depgraph even when skipping tests
[ https://jira.codehaus.org/browse/MNG-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311981#comment-311981 ] John Casey edited comment on MNG-5177 at 10/22/12 2:57 PM: --- IMO this is a dangerous thing to add without warning. Any plugin can specify '@RequiresDependencResolution test' and get tripped up with this patch, it's not only those that respond to maven.test.skip. In fact, I can think of use cases off the top of my head (creating a standalone buildable archive of a project using the assembly plugin being one) where test scope is needed, but have nothing at all to do with compiling/executing tests directly. If you want to avoid downloading test dependencies, you can move them into a profile that is activated when maven.test.skip == false. This works; I've used the technique. was (Author: jdcasey): IMO this is a dangerous thing to add without warning. Any plugin can specify '@RequiresDependencResolution test' and get tripped up with this patch, it's not only those that respond to maven.test.skip. In fact, I can think of use cases off the top of my head (creating a standalone buildable archive of a project using the assembly plugin being one) where test scope is needed, but have nothing at all to do with compiling/executing tests directly. Maven adds tests dependecies into depgraph even when skipping tests --- Key: MNG-5177 URL: https://jira.codehaus.org/browse/MNG-5177 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Reporter: Stanislav Ochotnicky Priority: Minor Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch Maven 3.x adds test dependencies into dependency graph even when we use -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and failure of build if the repository with test dependencies is offline. I was able to solve this by patching maven in following way: 1. add new DependencySelector implementation that looks at environment variables and omits test dependencies when maven.test.skip property is found 2. modify maven-compat as well so that old code paths work the same way. Maybe a better way to do part 1 would be to modify ScopeDependencySelector, and if that's the preferred way I can rework the patch that way. I had several issues with the implementation: 1. For some reason I wasn't able to get property definition from MavenSession so I used System.getProperty directly. Any idea what might be the reason? 2. Is there perhaps a better way to figure out that tests are being skipped instead of looking for maven.test.skip property? 3. I had to copy non-test artifacts of dependencies in DefaultArtifactResolver because original implementation didn't provide remove method. Not a big deal I guess, but worth a note. -- 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-5177) Maven adds tests dependecies into depgraph even when skipping tests
[ https://jira.codehaus.org/browse/MNG-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-5177. --- Resolution: Won't Fix Assignee: John Casey This changes the behavior of core Maven for all plugins that may require test-scoped dependencies. It's a mistake to think only of those that compile or execute tests, or that respond to maven.test.skip. There are less invasive ways to achieve the stated goal with Maven as-is. Maven adds tests dependecies into depgraph even when skipping tests --- Key: MNG-5177 URL: https://jira.codehaus.org/browse/MNG-5177 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Reporter: Stanislav Ochotnicky Assignee: John Casey Priority: Minor Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch Maven 3.x adds test dependencies into dependency graph even when we use -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and failure of build if the repository with test dependencies is offline. I was able to solve this by patching maven in following way: 1. add new DependencySelector implementation that looks at environment variables and omits test dependencies when maven.test.skip property is found 2. modify maven-compat as well so that old code paths work the same way. Maybe a better way to do part 1 would be to modify ScopeDependencySelector, and if that's the preferred way I can rework the patch that way. I had several issues with the implementation: 1. For some reason I wasn't able to get property definition from MavenSession so I used System.getProperty directly. Any idea what might be the reason? 2. Is there perhaps a better way to figure out that tests are being skipped instead of looking for maven.test.skip property? 3. I had to copy non-test artifacts of dependencies in DefaultArtifactResolver because original implementation didn't provide remove method. Not a big deal I guess, but worth a note. -- 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-5177) Maven adds tests dependecies into depgraph even when skipping tests
[ https://jira.codehaus.org/browse/MNG-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311986#comment-311986 ] Nick Cross commented on MNG-5177: - This also breaks the scenario when someone uses mvn -Dmaven.test.skip=false (where there is profile activated tests). Maven adds tests dependecies into depgraph even when skipping tests --- Key: MNG-5177 URL: https://jira.codehaus.org/browse/MNG-5177 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Reporter: Stanislav Ochotnicky Assignee: John Casey Priority: Minor Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch Maven 3.x adds test dependencies into dependency graph even when we use -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and failure of build if the repository with test dependencies is offline. I was able to solve this by patching maven in following way: 1. add new DependencySelector implementation that looks at environment variables and omits test dependencies when maven.test.skip property is found 2. modify maven-compat as well so that old code paths work the same way. Maybe a better way to do part 1 would be to modify ScopeDependencySelector, and if that's the preferred way I can rework the patch that way. I had several issues with the implementation: 1. For some reason I wasn't able to get property definition from MavenSession so I used System.getProperty directly. Any idea what might be the reason? 2. Is there perhaps a better way to figure out that tests are being skipped instead of looking for maven.test.skip property? 3. I had to copy non-test artifacts of dependencies in DefaultArtifactResolver because original implementation didn't provide remove method. Not a big deal I guess, but worth a note. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311987#comment-311987 ] Tim McCune commented on MNG-624: Change By: Olivier Lamy (22/Oct/12 2:39 PM) Deleted Comment:Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. Hey Olivier, just curious, why did you delete that comment? Seems like a good idea... automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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] (MECLIPSE-735) Ignore warnings for generated source directories
Jeremy Gustie created MECLIPSE-735:
--
Summary: Ignore warnings for generated source directories
Key: MECLIPSE-735
URL: https://jira.codehaus.org/browse/MECLIPSE-735
Project: Maven 2.x Eclipse Plugin
Issue Type: New Feature
Components: Core : Dependencies resolution and build path (.classpath)
Reporter: Jeremy Gustie
Eclipse has added the ability to ignore warnings for specific source
directories (see [Bug
220928|https://bugs.eclipse.org/bugs/show_bug.cgi?id=220928]), it would be nice
if source folders located under the build directory automatically got an
{{ignore_optional_problems}} attribute set to {{true}} so generated code does
not produce warnings:
{code}
classpathentry including=**/*.java kind=src
path=target/generated-sources
attributes
attribute name=ignore_optional_problems value=true/
/attributes
/classpathentry
{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] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-624: -- Comment: was deleted (was: Change By:Olivier Lamy (22/Oct/12 2:39 PM) Deleted Comment:Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. Hey Olivier, just curious, why did you delete that comment? Seems like a good idea...) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311989#comment-311989 ] Brian Fox commented on MNG-624: --- Tim, Tony, Jira shouldn't be used for advertising of services. The merit of the idea is moot. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-5102: --- Comment: was deleted (was: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/35/mixin-pom-fragments and throw in a few bucks for it.) Mixin POM fragments --- Key: MNG-5102 URL: https://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: 3.2 Attachments: daddy3.zip, maven-tiles.zip I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- 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] (MSHADE-36) Dependency reduced pom does not replace the packaged META-INF/maven version
[ https://jira.codehaus.org/browse/MSHADE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311990#comment-311990 ] Hung Huynh commented on MSHADE-36: -- I prefer this as a built-in default feature since it's expected rather an exception. However, users should be able to turn this off if they want to Dependency reduced pom does not replace the packaged META-INF/maven version --- Key: MSHADE-36 URL: https://jira.codehaus.org/browse/MSHADE-36 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Mark Hobson The dependency reduced pom needs to replace the packaged pom at: META-INF/maven/groupId/artifactId/pom.xml This will allow tools that use this metadata to read the correct shaded dependencies (e.g. maven-runtime). -- 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-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-4565: --- Comment: was deleted (was: From the looks of the details (assignee, fix version), doesn't look very promising. Maybe this issue needs some [sponsoring|http://www.freedomsponsors.org//core/issue/sponsor?trackerURL=http://jira.codehaus.org/browse/MNG-4565] :-) Have anyone tried Eric's github fork? ) Multiple profile activation conditions does not work Key: MNG-4565 URL: https://jira.codehaus.org/browse/MNG-4565 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.2.1 Environment: All platforms. Reporter: Nicholas Allen Fix For: Issues to be reviewed for 3.x According to the documentation at http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html a profile is activated when all activation conditions are met (which makes sense of course). But when I try to use this it does not work. It seems maven does an OR instead of an AND (which is not rearly as useful and is the opposite of what the documentation says at the previous link). For example, if I have one profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os /activation and another profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os property namerelease/name valuetrue/value /property /activation Then I would expect the second profile to only be activated if the OS is linux and the release property is defined. When I run 'mvn help:active-profiles' however, maven shows that both profiles are active even though the release property is not defined. -- 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-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reassigned MNG-4565: -- Assignee: Brian Fox Multiple profile activation conditions does not work Key: MNG-4565 URL: https://jira.codehaus.org/browse/MNG-4565 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.2.1 Environment: All platforms. Reporter: Nicholas Allen Assignee: Brian Fox Fix For: Issues to be reviewed for 3.x According to the documentation at http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html a profile is activated when all activation conditions are met (which makes sense of course). But when I try to use this it does not work. It seems maven does an OR instead of an AND (which is not rearly as useful and is the opposite of what the documentation says at the previous link). For example, if I have one profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os /activation and another profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os property namerelease/name valuetrue/value /property /activation Then I would expect the second profile to only be activated if the OS is linux and the release property is defined. When I run 'mvn help:active-profiles' however, maven shows that both profiles are active even though the release property is not defined. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311992#comment-311992 ] Sebastien Tardif commented on MNG-624: -- I agree that Jira shouldn't be used for advertising of services, but since this issue is visibly dragging a lot, even if having so many votes, and that somebody already committed to pay to get the issue resolved, the timing of complaining about this couldn't be worst ;-) As a positive point, at least it's not the assignee that slowed down a path to resolution. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-131) Excluding tests with command line pattern
[
https://jira.codehaus.org/browse/SUREFIRE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311995#comment-311995
]
Shane Witbeck commented on SUREFIRE-131:
I'm voting this up because there doesn't seem to be a way to include/exclude
TestNG test groups other than through path patterns like what's suggested here.
See:
http://stackoverflow.com/questions/7150302/excluding-testng-groups-from-maven
Excluding tests with command line pattern
-
Key: SUREFIRE-131
URL: https://jira.codehaus.org/browse/SUREFIRE-131
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Plugin
Affects Versions: 2.0 (2.2 plugin)
Environment: All environments running JUnit tests
Reporter: Johannes Carlén
Priority: Minor
Fix For: Backlog
I'd like to be able to exclude certain tests from being run. An example of
this could be a scenario where I'd like just the unit tests and not the
integration tests to run. In our case, we name all integration test with the
postfix IntTest instead of just Test.
This is now possible through configuring the plugin in the pom, however it is
not possible to decide at the command line if I just like to run some tests
and not all.
Example of use with this implementation would be:
mvn -Dexclude=*IntTest test
which would run all tests - excluding those that ends with IntTest
The amount of code needed for implementation is minimal. In
SurefirePlugin.java:
Just add a property - something like:
/**
* Specify this parameter to exclude test by their name. It follows
* the same conventions as the codetest/code parameter.
*
* @parameter expression=${exclude}
*
*/
private String exclude;
Add this code at line 527
if ( this.exclude != null )
{
String exclude = **/ + this.exclude + .java;
excludes.add(exclude);
getLog().debug( Excluding test with pattern : + exclude
);
}
...and that's all.
--
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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311996#comment-311996 ] Tony Lampada commented on MNG-624: -- Brian, Olivier. My apologies, I didn't mean to sound spammy or anything. I will not post comments like this one on Maven JIRA again. Let me just say that my intentions were pure though :-) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311997#comment-311997 ] Tony Lampada commented on MNG-624: -- Ah, just one question though. FreedomSponsors encourages users to post back on the original tracker when they sponsor new offers. That is the only way that developers can be notified about the offers. If people start to sponsor Maven issues and tell about it on Maven JIRA, will those comments be deleted as well? automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311998#comment-311998 ] Olivier Lamy commented on MNG-624: -- Probably yes. Please post here only patches or technical comments on issues. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-797) support semantic versioning
Matthew Daniel created MRELEASE-797:
---
Summary: support semantic versioning
Key: MRELEASE-797
URL: https://jira.codehaus.org/browse/MRELEASE-797
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: update-versions
Affects Versions: 2.3.2
Environment: Maven 3.0.4
Reporter: Matthew Daniel
Priority: Minor
When a project is using [semantic versioning|http://semver.org/], the
maven-release-plugin will only increment the right-most version identifier
(which corresponds to a patch release in semver terminology). It would be
helpful if the maven-release-plugin understood the 3 normal release severities:
major, minor and patch.
Current behavior:
# Given a {{pom.xml}} with version {{1.0.50-SNAPSHOT}}
# When the user executes {{mvn release:update-versions -Dsemver=major}} (as a
hypothetical syntax)
# Then observe that {{pom.xml}} contains {{1.0.51-SNAPSHOT}}, not
{{2.0.0-SNAPSHOT}} as a major release would dictate
Expected behavior:
# Given a pom version in {{X.Y.Z}} format
# When one indicates the desired semantic version release level to
maven-release-plugin
# Then maven-release-plugin increments {{X.Y.Z}} according to the user's
indicated release level
It would be an error condition for the user to request a semantic version
release level when the pom's version is not in {{X.Y.Z}} format (plus any
miscellaneous trailing text as specified in rules 10, 11 or 12 of the semver
specification).
It is currently possible to work around this via manual construction of a
{{release.properties}} file, but that requires a 2 step build process: run the
script then run the Maven targets. Further, one would expect that all Maven
projects that use semantic versioning would need to implement their own
pre-release scripts, which is wasteful.
--
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-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5315:
---
Description:
Artifact resolution can fail during the parallel build if it was downloaded
during the same session.
Scenario:
1) Delete the whole Maven local repository.
2) Run build mvn compile -T1.5C
3) Build fails (see log extracts below)
4) If I run build again, it succeeds.
It seems like the problem is due to two thread trying to resolve same artifact
concurrently. This problem never happens once I have all dependencies cached in
the local repository.
Extracts from the log output:
{noformat}Downloading:
http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
12444/13937 KB ...
...
[DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
already updated during this session.
[DEBUG] Skipped remote update check for
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4, already
updated during this session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
already updated during this session.
...
[ERROR] Failed to execute goal on project util: Could not resolve dependencies
for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts
could not be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, org.slf4j:slf4j-api:jar:1.6.4,
org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to find
commons-cli:commons-cli:jar:1.2 in http://nexus/content/repositories/thirdparty
was cached in the local repository, resolution will not be reattempted until
the update interval of gw.thirdparty has elapsed or updates are forced - [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
on project util: Could not resolve dependencies for project
com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not be
resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, org.slf4j:slf4j-api:jar:1.6.4,
org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to find
commons-cli:commons-cli:jar:1.2 in http://nexus/content/repositories/thirdparty
was cached in the local repository, resolution will not be reattempted until
the update interval of gw.thirdparty has elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
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.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.project.DependencyResolutionException: Could not
resolve dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, org.slf4j:slf4j-api:jar:1.6.4,
org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to find
commons-cli:commons-cli:jar:1.2 in http://nexus/content/repositories/thirdparty
was cached in the local repository, resolution will not be reattempted until
the update interval of gw.thirdparty has elapsed or updates are forced
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:189)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:185)
[jira] (MSHADE-132) Shade does not buffer output, yielding excessive write syscalls
Andrew Gaul created MSHADE-132: -- Summary: Shade does not buffer output, yielding excessive write syscalls Key: MSHADE-132 URL: https://jira.codehaus.org/browse/MSHADE-132 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Andrew Gaul Attachments: maven_shade_buffer_output.patch Shade does not buffer output, yielding excessive write syscalls. This slows down mvn package of a local project on a Linux ecryptfs volume from 34s to 3m47s. I attached a patch to address 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
