You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2008/06/13 04:38:12 UTC

[jira] Updated: (MNG-3454) processing a relocation erases requested version range

     [ http://jira.codehaus.org/browse/MNG-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter updated MNG-3454:
------------------------------

    Fix Version/s: 2.0.x

> processing a relocation erases requested version range
> ------------------------------------------------------
>
>                 Key: MNG-3454
>                 URL: http://jira.codehaus.org/browse/MNG-3454
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Artifacts and Repositories
>    Affects Versions: 2.0.5, 2.0.6, 2.0.7, 2.0.8
>            Reporter: Brian Fox
>            Priority: Minor
>             Fix For: 2.0.x
>
>         Attachments: MNG-2861.tar.gz, MNG-2861_broken.zip
>
>
> While fixing MNG-2861, I came across a weird scenario where the contents of the relocation can affect what happens. In 2861, the relocation did not specify a version, only a group id. However, if a version is specified, in MavenMetadataSource: 164 the versionRange is reset to the contents of the relocation.getVersion(). This effectively tosses out the requested range information. We only get here after selecting the version that has been relocated, but now we have a recommended version, which can cause a different version to be selected. See the two sample projects in MNG-2861 to see how the handling is different. (brett's version has the version in the relocation and thus expresses the behavior described here)
> The fix is simple, change the line to:
>                         if ( relocation.getVersion() != null )
>                         {
>                             //we don't want to blast the versionRange information
>                             artifact.selectVersion( relocation.getVersion() );
>                         }
> however, I'm not certain what the ramifications of this are. The potential exists for having selected a version that no longer matches the requested version range. Say the version range was [1.0,2.0] and 2.0 was relocated to 3.0. The fix to 2861 involves reloading the available versions from the relocated artifact. This means that there is no not an artifact to match 1.0-2.0 and who knows what's going to happen.
> I'm choosing to document this and not fix it for now due to the risk of instability. A search of open issues didn't result in anyone experiencing trouble with this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira