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.
