You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Thomas Mortagne (JIRA)" <ji...@apache.org> on 2016/06/24 08:32:16 UTC
[jira] [Updated] (MNG-6050) Version range dependency resolution
lost when version folder is missing from local repository
[ https://issues.apache.org/jira/browse/MNG-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mortagne updated MNG-6050:
---------------------------------
Description:
Here is the my situation:
* project {{mygroupid:a}} in version {{1.0-SNAPSHOT}}
* project {{mygroupid:b}} depends on {{mygroupid:a}} with version "range" {{\[1.0-SNAPSHOT]}} (it's actually {{\[$project.version]}} in my case)
If I remove the previously automatically downloaded {{~/.m2/repository/mygroupid/b/1.0-SNAPSHOT/}} folder and build {{mygroupid:b}}: it fail telling me it can't resolve the dependency. And it fail even when I use -U.
To make this situation work I have two choices:
* remove the whole A folder (i.e. get rid of metatada saying that there is a {{1.0-SNAPSHOT}} in the local repository)
* change from {{\[1.0-SNAPSHOT]}} to {{1.0-SNAPSHOT}}
I understand that it's not super clean to have metadata saying 1.0-SNAPSHOT is there when it's not true but:
* it's very handy sometime to just remove the folder corresponding to the version to test things
* it's not consistent with non ranged version behavior which has no issue with a missing version
* -U should not care about whatever is already there or not in local repository anyway
was:
Here is the my situation:
* project {{mygroupid:a}} in version {{1.0-SNAPSHOT}}
* project {{mygroupid:b}} depends on {{mygroupid:a}} with version "range" {{\[1.0-SNAPSHOT]}} (it's actually {{\[$project.version]}} in my case)
If I remove the {{~/.m2/repository/mygroupid/b/1.0-SNAPSHOT}} folder and build {{mygroupid:b}} it fail telling me it can't resolve the dependency. And it fail even when I use -U.
To make this situation work I have two choices:
* remove the whole A folder (i.e. get rid of metatada saying that there is a {{1.0-SNAPSHOT}} in the local repository)
* change from {{\[1.0-SNAPSHOT]}} to {{1.0-SNAPSHOT}}
I understand that it's not super clean to have metadata saying 1.0-SNAPSHOT is there when it's not true but:
* it's very handy sometime to just remove the folder corresponding to the version to test things
* it's not consistent with non ranged version behavior which has no issue with a missing version
* -U should not care about whatever is already there or not in local repository anyway
> Version range dependency resolution lost when version folder is missing from local repository
> ---------------------------------------------------------------------------------------------
>
> Key: MNG-6050
> URL: https://issues.apache.org/jira/browse/MNG-6050
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 3.3.9
> Reporter: Thomas Mortagne
>
> Here is the my situation:
> * project {{mygroupid:a}} in version {{1.0-SNAPSHOT}}
> * project {{mygroupid:b}} depends on {{mygroupid:a}} with version "range" {{\[1.0-SNAPSHOT]}} (it's actually {{\[$project.version]}} in my case)
> If I remove the previously automatically downloaded {{~/.m2/repository/mygroupid/b/1.0-SNAPSHOT/}} folder and build {{mygroupid:b}}: it fail telling me it can't resolve the dependency. And it fail even when I use -U.
> To make this situation work I have two choices:
> * remove the whole A folder (i.e. get rid of metatada saying that there is a {{1.0-SNAPSHOT}} in the local repository)
> * change from {{\[1.0-SNAPSHOT]}} to {{1.0-SNAPSHOT}}
> I understand that it's not super clean to have metadata saying 1.0-SNAPSHOT is there when it's not true but:
> * it's very handy sometime to just remove the folder corresponding to the version to test things
> * it's not consistent with non ranged version behavior which has no issue with a missing version
> * -U should not care about whatever is already there or not in local repository anyway
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)