[
https://issues.apache.org/jira/browse/IVY-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Bailliez updated IVY-430:
----------------------------------
Attachment: cachemanager.patch
Patch fix the issue.
I use a slightly more complete prefix key as well as the hashcode. It's not
foolproof but should be good enough for now. I also added a equals/hashcode on
artifact origin for testing purposes, and added a basic unit test.
Added some javadocs while passing by.
> 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
> Attachments: cachemanager.patch
>
>
> 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.
