You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "Stephane Bailliez (JIRA)" <ji...@apache.org> on 2007/03/09 00:56:24 UTC
[jira] Created: (IVY-430) Cache is storing ArtifactOrigin
properties with no guarantee of unicity and types telescope during resolve.
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.
[jira] Updated: (IVY-430) Cache is storing ArtifactOrigin
properties with no guarantee of unicity and types telescope during resolve.
Posted by "Stephane Bailliez (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (IVY-430) Cache is storing ArtifactOrigin
properties with no guarantee of unicity and types telescope during resolve.
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (IVY-430) Cache is storing ArtifactOrigin
properties with no guarantee of unicity and types telescope during resolve.
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Hanin reassigned IVY-430:
--------------------------------
Assignee: Xavier Hanin
> 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
> Assigned To: Xavier Hanin
> 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.
[jira] Resolved: (IVY-430) Cache is storing ArtifactOrigin
properties with no guarantee of unicity and types telescope during resolve.
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Hanin resolved IVY-430.
------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
I've applied your patch with only a small modification in the test: I use a subdirectory of the temp directory as cache instead of the temp directory itself, to avoid deleting the whole temporary directory in the tearDown method. Indeed if another process is using a temporary file while you are running the test, the temporary file could be deleted by the test (as part of the directory).
Anyway, thanks a lot for your contribution, very clean code as usual, and sorry for misspelling your name.
> 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
> Assigned To: Xavier Hanin
> Fix For: 2.0.0-alpha-2
>
> 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.