[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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=revision&revision=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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///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: > > false > >linux > > > and another profile that is activated like this: > > false > >linux > > > release > true > > > 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: > > false > >linux > > > and another profile that is activated like this: > > false > >linux > > > release > true > > > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 test 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:18
[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
