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

Brian Fox updated MNG-3454:
---------------------------

    Attachment: MNG-2861.tar.gz

> 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
>         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

        

Reply via email to