[
https://issues.apache.org/jira/browse/IVY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
easyproglife updated IVY-433:
-----------------------------
Fix Version/s: (was: 1.5)
unspecified
Description:
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 :-)
was:
In trying to deliver an ivy.xml, using the ant <deliver> task, for an artifact
which has a dependency on a "latest.release" revision of a specific branch the
dynamic revision is not getting replaced with the static rev. Here is what the
dependency looks like:
<dependency name="my-framework" rev="latest.release" branch="fix_for_release"/>
If I remove the branch indicator the latest HEAD revision gets used and the rev
attribute gets updated correctly. If I add the branch attribute the correct
dependent branch release jar gets used, but the dynamic revision of the
published ivy stays "latest.release".
> 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.
