Maven 2 & 3

Ranges with inclusive upper bounds are not validated against metadata

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.6
  • Fix Version/s: 2.0.7
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Issue Links

This issue is related to:
MRELEASE-177 generateReleasePoms does not work Critical Closed
MNG-1142 restriction of [1.6,) and [1.5,1.6.2) in that order results in 1.6.2 instead of 1.6.1 Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason van Zyl added a comment -

Please put the description in the issue. One the beauties of Mylar is working completely offline which is not possible with external reference to the actual issues. It's bad practice not to have the intact set of information associated with the issue itself.

Show
Jason van Zyl added a comment - Please put the description in the issue. One the beauties of Mylar is working completely offline which is not possible with external reference to the actual issues. It's bad practice not to have the intact set of information associated with the issue itself.
Hide
Permalink
Jason van Zyl added a comment -

From Mark's email:

I'm working on tests for MRELEASE-177 which has led me to investigate
how ranges are resolved. An example problem was [1.0,2.0] resolving
to 2.0 irrespective of the repository metadata.

This appears to be due to VersionRange.getSelectedVersion and
isSelectedVersionKnown which selects the upper bound if present and
inclusive. DefaultArtifactCollector then blindly uses this without
consulting the artifact metadata. Any idea why VersionRange special
cases this situation? All the integration tests pass without it.

Show
Jason van Zyl added a comment - From Mark's email: I'm working on tests for MRELEASE-177 which has led me to investigate how ranges are resolved. An example problem was [1.0,2.0] resolving to 2.0 irrespective of the repository metadata. This appears to be due to VersionRange.getSelectedVersion and isSelectedVersionKnown which selects the upper bound if present and inclusive. DefaultArtifactCollector then blindly uses this without consulting the artifact metadata. Any idea why VersionRange special cases this situation? All the integration tests pass without it.
Hide
Permalink
Brett Porter added a comment -

applied to trunk and branch

Show
Brett Porter added a comment - applied to trunk and branch

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.