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