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