[
https://issues.apache.org/jira/browse/IVY-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479527
]
Xavier Hanin commented on IVY-430:
----------------------------------
Good catch. What identifies an artifact is an ArtifactRevisionId, and if we
check the code, we can see that the equals method relies on:
- ModuleRevisionId (ie. org / module / revision)
- ArtifactId (ie. name / type / ext)
- extra attributes
So conf isn't part of the identifier, but ext and extra attributes are.
> Cache is storing ArtifactOrigin properties with no guarantee of unicity and
> types telescope during resolve.
> -----------------------------------------------------------------------------------------------------------
>
> Key: IVY-430
> URL: https://issues.apache.org/jira/browse/IVY-430
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.1
> Reporter: Stephane Bailliez
>
> I found what is causing the resolve to be completely lost when using
> useOrigin to true and you get complete nonsense of artifacts with different
> type.
> The reason is the cache implementation which use a key which has no guarantee
> to be unique for an artifact and in my case it just does not work
> I have artifacts which have the same name and extension but different types
> (jar, source, javadoc, war, deb).
> the key is computed with 'artifact." + artifact.getName() + "#" +
> artifact.getExt() + ".location"
> So of course it will not work when you try to grab ArtifactOrigin of Artifact
> with same name an ext and different types, since it will think it is there
> and you will get the origin of the first artifact that ended up in the cache.
> So the key should at the very least include the type as well. (I'm also
> wondering about other properties ? conf ?
> I'm working on a patch when I have time to do that, but let's clarify first
> what is identifying an artifact.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
