[
https://issues.apache.org/jira/browse/IVY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-433:
------------------------------
Fix Version/s: (was: unspecified)
2.0.0-alpha-1
> CLONE -Static revision replacement is not working when delivering an artifact
> with a dependency with extra attributes
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: IVY-433
> URL: https://issues.apache.org/jira/browse/IVY-433
> Project: Ivy
> Issue Type: Bug
> Components: Ant, Core
> Affects Versions: 1.4.1
> Reporter: easyproglife
> Assignee: Xavier Hanin
> Priority: Critical
> Fix For: 2.0.0-alpha-1
>
>
> I was reading IVY-404 and I thought it fixed my case but it doesn't.
> In my case, I have module A depends on module B. Module B has an extra
> attribute called "folder".
> Module A depends on "latest.integration" (or any other dynamic revision) of
> module B.
> After "deliver" of module A, the revision of module B in the generated
> ivy.xml is still dynamic.
> After hours of investigating the source code I got an insight about the
> reason for that:
> It's all about the HashMap called "resolvedRevisions" that being passed in
> Ivy.java:2249 to XmlModuleDescriptorUpdater.update() method.
> This HashMap contains mapping from a resolved ModuleRevisionId object to its
> concrete revision (as were resolved in the cache). It is based on all the
> attributes including the extra attributes.
> XmlModuleDescriptorUpdater in its turn, constructs its own ModuleRevisionId
> (localMid, line 193) based on org, module, branch and revision.
> HashMap "get"s objects by the "equals" method (see:
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Map.html and
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/IdentityHashMap.html)
> Therefore, if we want to make sure dynamic revisions translate to static
> during deliver we must make sure that both ModuleRevisionId are "equals".
> Since XmlModuleDescriptorUpdater constructs ModuleRevisionId only by 4
> attributes: org, module, branch and revision, I think that the equals method
> of ModuleRevisionId should not take into account the extra attributes
> (meaning to remove line 89). The same is true for hashCode: don't take extra
> attributes into account.
> I have tested this on my environment and it's working!
> If you think that changing equlas and hashCode mothods of ModuleRevisionId in
> the way I suggested above is not correct, you have to do something else in
> order to fix the bug: you have to use RAW STRING keys in resolvedRevisions
> based on those 4 attributes: org, module, branch and revision. Don't use the
> ModuleRevisionId object itself as a key!
> A deeper thought must be taken where the number of extra attributes is differ
> in the dependency element of the using module (module A) and in the info
> element of the dependent module (module B).
> In my suggestion above, extra attributes don't be taken into account at all.
> Maybe only the intersection of the extra attributes from both modules should
> be compared.
> I hope this issue got understood despite its length :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
