ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maarten Coene (JIRA)" <j...@apache.org>
Subject [jira] Updated: (IVY-433) CLONE -Static revision replacement is not working when delivering an artifact with a dependency with extra attributes
Date Thu, 19 Mar 2009 20:39:50 GMT

     [ 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.


Mime
View raw message