You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Garrett Conaty (JIRA)" <ji...@codehaus.org> on 2006/02/21 21:27:01 UTC
[jira] Created: (MNG-2098) Artifact resolver incorrectly selects
repository which doesn't contain the selected version
Artifact resolver incorrectly selects repository which doesn't contain the selected version
-------------------------------------------------------------------------------------------
Key: MNG-2098
URL: http://jira.codehaus.org/browse/MNG-2098
Project: Maven 2
Type: Bug
Components: Artifacts and Repositories
Versions: 2.0.2
Reporter: Garrett Conaty
Attachments: MNG-2098.simplefix.diff, pom.xml
The current logic for resolution of an artifact which has groupId/artifactId and then a range is for the DefaultArtifactCollector to call MavenMetadataSource and retrieve the available versions and then match the available versions to the range.
However, a side effect exists in that the DefaultRepositoryMetadataManager in its call to mergeMetadata sets the repository for the artifact. It currently just sets it to the last repository that had versions to merge. What occurs here though is that it can be set to a repository that doesn't actually have the artifact that is selected as part of the match of version range to available versions. Then when this artifact is passed to the resolver to download the JAR it references, it of course can't find it and an exception is thrown.
So there are a couple of issues here
1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null? Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try. This may be a good enhancment.
but the more pressing issue is
2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata.
The simple patch I've attached solves the problem by just removing the call to setRepository in the mergeMetadata method. This has the effect that there will be no repository chosen by the time the DefaultArtifactResolver gets a hold of the artifact and it will then go through the list of remoteRepositories until it finds a succesful match.
What I'd like to do though is really modify the DefaultArtifactCollector and MavenMetadataSource so that the collector can make the decision about what repository/list of repositories to use, and in the very least choose the repository that has the version that was matched in the range.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-2098) Artifact resolver incorrectly selects
repository which doesn't contain the selected version
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2098?page=comments#action_60188 ]
Brett Porter commented on MNG-2098:
-----------------------------------
from dev@:
Setting the repository is not exactly a side effect of resolving metadata, but I see why its a bug.
However, the collector can't select the repository as it doesn't know where it will be present.
The current logic is based on the use of snapshots - it considered that
releases would only be in one so the first found is used, whereas for
snapshots all must be checked and the newest used. I believe it works
for the latter.
It seems to be falling down only for version ranges, correct? I had
thought these should also operate as a transformation but that doesn't
sit with the whole resolution technique.
The actual version selection should be assigning a single repository to
it where the correct version was found.
This area of the code needs a lot more tests, in the order of what the
collector itself has. I suspect doing so will probably yield a lot of
clues for a better design also.
> Artifact resolver incorrectly selects repository which doesn't contain the selected version
> -------------------------------------------------------------------------------------------
>
> Key: MNG-2098
> URL: http://jira.codehaus.org/browse/MNG-2098
> Project: Maven 2
> Type: Bug
> Components: Artifacts and Repositories
> Versions: 2.0.2
> Reporter: Garrett Conaty
> Attachments: MNG-2098.simplefix.diff, pom.xml
>
>
> The current logic for resolution of an artifact which has groupId/artifactId and then a range is for the DefaultArtifactCollector to call MavenMetadataSource and retrieve the available versions and then match the available versions to the range.
> However, a side effect exists in that the DefaultRepositoryMetadataManager in its call to mergeMetadata sets the repository for the artifact. It currently just sets it to the last repository that had versions to merge. What occurs here though is that it can be set to a repository that doesn't actually have the artifact that is selected as part of the match of version range to available versions. Then when this artifact is passed to the resolver to download the JAR it references, it of course can't find it and an exception is thrown.
> So there are a couple of issues here
> 1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null? Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try. This may be a good enhancment.
> but the more pressing issue is
> 2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata.
> The simple patch I've attached solves the problem by just removing the call to setRepository in the mergeMetadata method. This has the effect that there will be no repository chosen by the time the DefaultArtifactResolver gets a hold of the artifact and it will then go through the list of remoteRepositories until it finds a succesful match.
> What I'd like to do though is really modify the DefaultArtifactCollector and MavenMetadataSource so that the collector can make the decision about what repository/list of repositories to use, and in the very least choose the repository that has the version that was matched in the range.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-2098) Artifact resolver incorrectly selects
repository which doesn't contain the selected version
Posted by "Garrett Conaty (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2098?page=all ]
Garrett Conaty updated MNG-2098:
--------------------------------
Attachment: MNG-2098.simplefix.diff
> Artifact resolver incorrectly selects repository which doesn't contain the selected version
> -------------------------------------------------------------------------------------------
>
> Key: MNG-2098
> URL: http://jira.codehaus.org/browse/MNG-2098
> Project: Maven 2
> Type: Bug
> Components: Artifacts and Repositories
> Versions: 2.0.2
> Reporter: Garrett Conaty
> Attachments: MNG-2098.simplefix.diff, pom.xml
>
>
> The current logic for resolution of an artifact which has groupId/artifactId and then a range is for the DefaultArtifactCollector to call MavenMetadataSource and retrieve the available versions and then match the available versions to the range.
> However, a side effect exists in that the DefaultRepositoryMetadataManager in its call to mergeMetadata sets the repository for the artifact. It currently just sets it to the last repository that had versions to merge. What occurs here though is that it can be set to a repository that doesn't actually have the artifact that is selected as part of the match of version range to available versions. Then when this artifact is passed to the resolver to download the JAR it references, it of course can't find it and an exception is thrown.
> So there are a couple of issues here
> 1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null? Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try. This may be a good enhancment.
> but the more pressing issue is
> 2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata.
> The simple patch I've attached solves the problem by just removing the call to setRepository in the mergeMetadata method. This has the effect that there will be no repository chosen by the time the DefaultArtifactResolver gets a hold of the artifact and it will then go through the list of remoteRepositories until it finds a succesful match.
> What I'd like to do though is really modify the DefaultArtifactCollector and MavenMetadataSource so that the collector can make the decision about what repository/list of repositories to use, and in the very least choose the repository that has the version that was matched in the range.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-2098) Artifact resolver incorrectly selects
repository which doesn't contain the selected version
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2098?page=comments#action_60098 ]
Brett Porter commented on MNG-2098:
-----------------------------------
I believe the simple fix has more consequence than to just change the number of repos searched, but I'd need to investigate. This requires more careful consideration.
> Artifact resolver incorrectly selects repository which doesn't contain the selected version
> -------------------------------------------------------------------------------------------
>
> Key: MNG-2098
> URL: http://jira.codehaus.org/browse/MNG-2098
> Project: Maven 2
> Type: Bug
> Components: Artifacts and Repositories
> Versions: 2.0.2
> Reporter: Garrett Conaty
> Attachments: MNG-2098.simplefix.diff, pom.xml
>
>
> The current logic for resolution of an artifact which has groupId/artifactId and then a range is for the DefaultArtifactCollector to call MavenMetadataSource and retrieve the available versions and then match the available versions to the range.
> However, a side effect exists in that the DefaultRepositoryMetadataManager in its call to mergeMetadata sets the repository for the artifact. It currently just sets it to the last repository that had versions to merge. What occurs here though is that it can be set to a repository that doesn't actually have the artifact that is selected as part of the match of version range to available versions. Then when this artifact is passed to the resolver to download the JAR it references, it of course can't find it and an exception is thrown.
> So there are a couple of issues here
> 1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null? Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try. This may be a good enhancment.
> but the more pressing issue is
> 2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata.
> The simple patch I've attached solves the problem by just removing the call to setRepository in the mergeMetadata method. This has the effect that there will be no repository chosen by the time the DefaultArtifactResolver gets a hold of the artifact and it will then go through the list of remoteRepositories until it finds a succesful match.
> What I'd like to do though is really modify the DefaultArtifactCollector and MavenMetadataSource so that the collector can make the decision about what repository/list of repositories to use, and in the very least choose the repository that has the version that was matched in the range.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org