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 "easyproglife (JIRA)" <ji...@apache.org> on 2007/03/13 14:30:09 UTC
[jira] Created: (IVY-433) CLONE -Static revision replacement is not
working when delivering an artifact with a dependency with extra attributes
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: 1.5
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".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-433) CLONE -Static revision replacement is
not working when delivering an artifact with a dependency with extra
attributes
Posted by "easyproglife (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482831 ]
easyproglife commented on IVY-433:
----------------------------------
Yes you are right. It solved my problem. the bug can be closed. :-)
> 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.
[jira] Commented: (IVY-433) CLONE -Static revision replacement is
not working when delivering an artifact with a dependency with extra
attributes
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480526 ]
Xavier Hanin commented on IVY-433:
----------------------------------
Good investigation, you're now an expert with Ivy internals :-)
But isn't your problem a duplicate of IVY-415? If it is, it's already solved both on 1.4.x branch, and on the trunk, with a different solution. Could you give it a try and see if it's working for you?
> 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.
[jira] Updated: (IVY-433) CLONE -Static revision replacement is not
working when delivering an artifact with a dependency with extra attributes
Posted by "easyproglife (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (IVY-433) CLONE -Static revision replacement is not
working when delivering an artifact with a dependency with extra attributes
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ 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.