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 "Xavier Hanin (JIRA)" <ji...@apache.org> on 2007/03/22 10:43:32 UTC

[jira] Closed: (IVY-433) CLONE -Static revision replacement is not working when delivering an artifact with a dependency with extra attributes

     [ https://issues.apache.org/jira/browse/IVY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xavier Hanin closed IVY-433.
----------------------------

    Resolution: Duplicate

> 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
>         Assigned To: Xavier Hanin
>            Priority: Critical
>             Fix For: unspecified
>
>
> 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.