From ivy-user-return-7221-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org Fri Sep 24 04:07:14 2010 Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 19415 invoked from network); 24 Sep 2010 04:07:14 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Sep 2010 04:07:14 -0000 Received: (qmail 50734 invoked by uid 500); 24 Sep 2010 04:07:14 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 50546 invoked by uid 500); 24 Sep 2010 04:07:12 -0000 Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@ant.apache.org Delivered-To: mailing list ivy-user@ant.apache.org Delivered-To: moderator for ivy-user@ant.apache.org Received: (qmail 92144 invoked by uid 99); 23 Sep 2010 21:22:58 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of cmyers@palantir.com designates 206.188.26.34 as permitted sender) Message-ID: <4C9BC506.1060908@palantir.com> Date: Thu, 23 Sep 2010 14:22:14 -0700 From: Carl Myers Reply-To: cmyers@palantir.com Organization: Palantir Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5 MIME-Version: 1.0 To: Subject: Re: Please vote: changing the default conflict manager References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Sadly, right now, it seems broke =( https://issues.apache.org/jira/browse/IVY-1228 To go ahead and give one anecdote, our dependency graphs are *very* complicated. We have two kinds of builds, "official" builds built by our continuous build (and continuous release) process, and local developer builds to "test before committing". Because our continuous release is releasing all the time, a local build fails because each module does its own resolve, which will resolve different dependencies (since the dependencies are in a constant state of flux). If, however, latest-compatible was in use, then the correct version should be used (because previously built modules would mean a transitive dependency on 1.0 which would lock us into 1.0, even though 1.1 has been released since the start of the build). Our usecase is probably atypical, very few people have dependency graphs as complex as ours, but it is a data point for you. We use strict dependency checking in our continuous build (and wherever possible) but we really need latest-compatible for our local builds for the above reasons. -Carl On 09/23/2010 09:49 AM, Mitch Gitman wrote: > Please forgive the tangent. Here's what the documentation has to say about > "latest-compatible": > this conflict manager selects the latest version in the conflicts which can > result in a compatible set of dependencies. This means that in the end this > conflict manager does not allow any conflict (like the strict conflict > manager), except that it follows a best effort strategy to try to find a set > of compatible modules (according to the version constraints) > > http://ant.apache.org/ivy/history/latest-milestone/settings/conflict-managers.html > > Can anyone out there articulate precisely what that means? -- Carl Myers Palantir Technologies | Internal Tools Software Engineer cmyers@palantir.com