From notifications-return-10783-apmail-ant-notifications-archive=ant.apache.org@ant.apache.org Fri Dec 04 11:40:45 2009 Return-Path: Delivered-To: apmail-ant-notifications-archive@minotaur.apache.org Received: (qmail 31164 invoked from network); 4 Dec 2009 11:40:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Dec 2009 11:40:45 -0000 Received: (qmail 76020 invoked by uid 500); 4 Dec 2009 11:40:45 -0000 Delivered-To: apmail-ant-notifications-archive@ant.apache.org Received: (qmail 75956 invoked by uid 500); 4 Dec 2009 11:40:44 -0000 Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ant.apache.org Delivered-To: mailing list notifications@ant.apache.org Received: (qmail 75947 invoked by uid 99); 4 Dec 2009 11:40:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2009 11:40:44 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2009 11:40:42 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id B1D66234C052 for ; Fri, 4 Dec 2009 03:40:20 -0800 (PST) Message-ID: <467111327.1259926820727.JavaMail.jira@brutus> Date: Fri, 4 Dec 2009 11:40:20 +0000 (UTC) From: "Carlton Brown (JIRA)" To: notifications@ant.apache.org Subject: [jira] Commented: (IVY-1148) Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts In-Reply-To: <1646445884.1259891120707.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on 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.