You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Carlton Brown (JIRA)" <ji...@apache.org> on 2009/12/04 02:45:20 UTC
[jira] Created: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
----------------------------------------------------------------------------------------------------------
Key: IVY-1148
URL: https://issues.apache.org/jira/browse/IVY-1148
Project: Ivy
Issue Type: Bug
Components: Ant
Affects Versions: 2.1.0, trunk
Environment: Windows or Linux, i386
Reporter: Carlton Brown
Fix For: trunk
Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IVY-1148) Encountered 'multiple
artifacts retrieved to same file' error when module does not have multiple
artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787196#action_12787196 ]
Maarten Coene edited comment on IVY-1148 at 12/8/09 8:37 AM:
-------------------------------------------------------------
I've made an update to the class IvyNode which I hope will fix the problem (but it's hard to tell without a junit test).
Could you please give it a try and post your feedback here?
EDIT: you might have to clean your ivy cache first
thanks;
Maarten
was (Author: maartenc):
I've made an update to the class IvyNode which I hope will fix the problem (but it's hard to tell without a junit test).
Could you please give it a try and post your feedback here?
thanks;
Maarten
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene updated IVY-1148:
-------------------------------
Affects Version/s: (was: trunk)
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IVY-1148) Encountered 'multiple
artifacts retrieved to same file' error when module does not have multiple
artifacts
Posted by "Carlton Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787468#action_12787468 ]
Carlton Brown edited comment on IVY-1148 at 12/8/09 2:21 PM:
-------------------------------------------------------------
The test passes in my environment with the latest trunk revision 888191. The failure does not occur anymore. Thanks for working on this with the incomplete information. Can you briefly explain the fix?
was (Author: carltonb):
The test passes in my environment with the latest trunk revision 888191. Thanks for working on this with the incomplete information. Can you briefly explain the fix?
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Carlton Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787468#action_12787468 ]
Carlton Brown commented on IVY-1148:
------------------------------------
The test passes in my environment with the latest trunk revision 888191. Thanks for working on this with the incomplete information. Can you briefly explain the fix?
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene resolved IVY-1148.
--------------------------------
Resolution: Fixed
Assignee: Maarten Coene
Thanks for the feedback, it could only be fixed so quickly thanks to your excellent detective/debugging work :-)
The ivy:merged attributes was introduced to fix IVY-537. That gave me a little understanding about this attribute, so all I did was to make sure that if for some reason such an merged artifact was also selected in a normal way, the merged artifact wasn't returned from IvyNode and so won't get retrieved by the RetrieveEngine.
Maarten
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene updated IVY-1148:
-------------------------------
Fix Version/s: 2.2.0-RC1
(was: trunk)
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.0
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Assignee: Maarten Coene
> Fix For: 2.2.0-RC1
>
> Attachments: ArtifactDownloadReport.patch, ivy_1148.xml
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787196#action_12787196 ]
Maarten Coene commented on IVY-1148:
------------------------------------
I've made an update to the class IvyNode which I hope will fix the problem (but it's hard to tell without a junit test).
Could you please give it a try and post your feedback here?
thanks;
Maarten
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785816#action_12785816 ]
Maarten Coene commented on IVY-1148:
------------------------------------
I think I've found a bug in the equals of AbstractArtifact (it doesn't compare the publicationDate properly), maybe this is causing your problem?
Maarten
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Carlton Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carlton Brown updated IVY-1148:
-------------------------------
Attachment: ArtifactDownloadReport.patch
Proposed solution that passes existing unit tests.
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Carlton Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785889#action_12785889 ]
Carlton Brown commented on IVY-1148:
------------------------------------
In my case the publication dates are equal. The false inequality causing the problem is definitely caused by inequality of the 'merged' qualifed extended attribute of AbstractArtifact. It is null for one artifact but not the other, yet these are in fact the same artifact.
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0, trunk
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene updated IVY-1148:
-------------------------------
Component/s: (was: Ant)
Core
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.0
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1148) Encountered 'multiple artifacts
retrieved to same file' error when module does not have multiple artifacts
Posted by "Mark Harrah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Harrah updated IVY-1148:
-----------------------------
Attachment: ivy_1148.xml
If you need a simple example for a unit test, the attached Ivy file works with trunk but not 2.1.0. In 2.1.0, it gives the error:
Multiple artifacts of the module commons-beanutils#commons-beanutils;1.8.2 are retrieved to the same file!
when using ivy:retrieve.
Thanks,
Mark
> Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>
> Key: IVY-1148
> URL: https://issues.apache.org/jira/browse/IVY-1148
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.0
> Environment: Windows or Linux, i386
> Reporter: Carlton Brown
> Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: ArtifactDownloadReport.patch, ivy_1148.xml
>
>
> Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts.
> I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts.
> It started happening when we started using the branch attribute in our modules. Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly.
> During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers.
> The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like:
> orgA#moduleA#trunk;build1245 -> orgB#moduleB#trunk;build833
> Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA.
> So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code.
> I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict.
> My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.