ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlton Brown (JIRA)" <>
Subject [jira] [Commented] (IVY-1148) Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
Date Wed, 06 Apr 2011 13:21:05 GMT


Carlton Brown commented on IVY-1148:

The bug wasn't to make that error go away forever, it was to ensure that the error is only
reported when the retrieve pattern truly has a problem.    

Since you didn't post your retrieve pattern, I can only guess at the problem, but the usual
mistake is assuming that modules only publish library jars.   If you're resolving a module
like commons-lang that publishes other jars (source jars, javadoc jars, etc) then you need
to incorporate  the [classifier] token in your retrieve pattern.   Here's an example: pattern="${lib.dir}/[conf]/[artifact](-[classifier]).[ext]"

> Encountered 'multiple artifacts retrieved to same file' error when module does not have
multiple artifacts
> ----------------------------------------------------------------------------------------------------------
>                 Key: IVY-1148
>                 URL:
>             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.
For more information on JIRA, see:

View raw message