[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322488#comment-322488 ] Kunalkumar Somani commented on MNG-3092: @Sergei, everyone has different view to look at the problem. We have gone back and forth on this behavior a couple time. I totally agree with Tuomas where he has mentioned in last paragraph, it will be very tedious for SNAPSHOT range removal before releasing and resetting after releasing. Agree with your idea and can release patch where User can pass property in maven command -DuseSnapshotInRange=false and it will exclude all SNAPSHOT from range, the default behavior is true, in that case we will have backward compatibility as well. It will not impact the existing behavior.The problem what I can see here is if we have range defined in parent POM then you need to ask reference POM to use this new parameter else it will pick latest SNAPSHOT if available in repository. If you all are agree on it please vote for it and will fix this bug. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322489#comment-322489 ] Tuomas Kiviaho commented on MNG-3092: - @Scott Sosna - I'm using snapshot inclusion blocking approach which is already quite well covered by Sergey. For other purposes the less intruding pluggable [Dependency Selector|http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution] approach as Jason suggested might be achievable even today by using javaagent and aspects. This would not require patching/forking nor tampering with current version range semantics. @Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way to combine the two separate settings.xml back to one using a system property or an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD line options could be omitted. PS. I don't mean any disrespect to anyone who has put effort - both in time and/or patience - on to solving this matter. Comic served just as a reminder that every change breaks someones workflow. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322489#comment-322489 ] Tuomas Kiviaho edited comment on MNG-3092 at 3/23/13 4:36 AM: -- @Scott Sosna - I'm using snapshot inclusion blocking approach which is already quite well covered by [Sergei|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=313516page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-313516]. For other purposes the less intruding pluggable [Dependency Selector|http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution] approach as Jason suggested might be achievable even today by using javaagent and aspects. This would not require patching/forking nor tampering with current version range semantics. @Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way to combine the two separate settings.xml back to one using a system property or an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD line options could be omitted. PS. I don't mean any disrespect to anyone who has put effort - both in time and/or patience - on to solving this matter. Comic served just as a reminder that every change breaks someones workflow. was (Author: tuomas_kiviaho): @Scott Sosna - I'm using snapshot inclusion blocking approach which is already quite well covered by Sergey. For other purposes the less intruding pluggable [Dependency Selector|http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution] approach as Jason suggested might be achievable even today by using javaagent and aspects. This would not require patching/forking nor tampering with current version range semantics. @Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way to combine the two separate settings.xml back to one using a system property or an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD line options could be omitted. PS. I don't mean any disrespect to anyone who has put effort - both in time and/or patience - on to solving this matter. Comic served just as a reminder that every change breaks someones workflow. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-281) Methods with Stringbased includes/excludes should also a List based version
[
https://jira.codehaus.org/browse/MSHARED-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MSHARED-281:
--
Assignee: Robert Scholte
Methods with Stringbased includes/excludes should also a List based version
---
Key: MSHARED-281
URL: https://jira.codehaus.org/browse/MSHARED-281
Project: Maven Shared Components
Issue Type: Bug
Components: maven-shared-utils
Affects Versions: maven-shared-utils-0.3
Reporter: Robert Scholte
Assignee: Robert Scholte
Most of the time {{includes}}/{{excludes}} are already Lists, so its quite
inefficient to transform these first to a comma-separated String and later
back to a List.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-281) Methods with Stringbased includes/excludes should also a List based version
Robert Scholte created MSHARED-281:
--
Summary: Methods with Stringbased includes/excludes should also a
List based version
Key: MSHARED-281
URL: https://jira.codehaus.org/browse/MSHARED-281
Project: Maven Shared Components
Issue Type: Bug
Components: maven-shared-utils
Affects Versions: maven-shared-utils-0.3
Reporter: Robert Scholte
Most of the time {{includes}}/{{excludes}} are already Lists, so its quite
inefficient to transform these first to a comma-separated String and later back
to a List.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322488#comment-322488 ] Kunalkumar Somani edited comment on MNG-3092 at 3/23/13 1:38 PM: - @Sergei, everyone has different view to look at the problem. We have gone back and forth on this behavior a couple time. I totally agree with Tuomas where he has mentioned in last paragraph, it will be very tedious for SNAPSHOT range removal before releasing and resetting after releasing. Agree with your idea and can release patch where User can pass property in maven command -DuseSnapshotInRange=false and it will exclude all SNAPSHOT from range, the default behavior is true, in that case we will have backward compatibility as well. It will not impact the existing behavior.The problem what I can see here is if we have range defined in parent POM then you need to ask reference POM to use this new parameter else it will pick latest SNAPSHOT if available in repository. was (Author: kunalsomani): @Sergei, everyone has different view to look at the problem. We have gone back and forth on this behavior a couple time. I totally agree with Tuomas where he has mentioned in last paragraph, it will be very tedious for SNAPSHOT range removal before releasing and resetting after releasing. Agree with your idea and can release patch where User can pass property in maven command -DuseSnapshotInRange=false and it will exclude all SNAPSHOT from range, the default behavior is true, in that case we will have backward compatibility as well. It will not impact the existing behavior.The problem what I can see here is if we have range defined in parent POM then you need to ask reference POM to use this new parameter else it will pick latest SNAPSHOT if available in repository. If you all are agree on it please vote for it and will fix this bug. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322488#comment-322488 ] Kunalkumar Somani edited comment on MNG-3092 at 3/23/13 1:58 PM: - @Sergei, everyone has different view to look at the problem. We have gone back and forth on this behavior a couple time. I totally agree with Tuomas where he has mentioned in last paragraph, it will be very tedious for SNAPSHOT range removal before releasing and resetting after releasing. Agree with your idea and can release patch where User can pass property in maven command -DuseSnapshotInRange=false and it will exclude all SNAPSHOT from range, the default behavior is true, in that case we will have backward compatibility as well. It will not impact the existing behavior. The problem what I can see here is if we have range defined in parent POM then you need to ask reference POM to use this new parameter else it will pick latest SNAPSHOT if available in repository. was (Author: kunalsomani): @Sergei, everyone has different view to look at the problem. We have gone back and forth on this behavior a couple time. I totally agree with Tuomas where he has mentioned in last paragraph, it will be very tedious for SNAPSHOT range removal before releasing and resetting after releasing. Agree with your idea and can release patch where User can pass property in maven command -DuseSnapshotInRange=false and it will exclude all SNAPSHOT from range, the default behavior is true, in that case we will have backward compatibility as well. It will not impact the existing behavior.The problem what I can see here is if we have range defined in parent POM then you need to ask reference POM to use this new parameter else it will pick latest SNAPSHOT if available in repository. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322508#comment-322508 ] Joniec Jacek commented on MNG-3092: --- This way we will never come to a conclusion. @Tuomas, the other approach what you have mentioned requires a lot of effort. I totally disagree to modifying setting.xml file because there is more risk as normally the user does not change this file. At this moment we are looking for a simple solution and I totally agree with Sergei and Kunalkumar if we give option in CMD line it will be more flexible,easily understood and traceable. We are stretching the problem to far we just need a simple solution. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
