From ivy-user-return-2953-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org Wed Apr 02 22:55:06 2008 Return-Path: Delivered-To: apmail-ant-ivy-user-archive@www.apache.org Received: (qmail 30418 invoked from network); 2 Apr 2008 22:55:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Apr 2008 22:55:05 -0000 Received: (qmail 48279 invoked by uid 500); 2 Apr 2008 22:55:05 -0000 Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org Received: (qmail 48266 invoked by uid 500); 2 Apr 2008 22:55:05 -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 Received: (qmail 48257 invoked by uid 99); 2 Apr 2008 22:55:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Apr 2008 15:55:04 -0700 X-ASF-Spam-Status: No, hits=-1.9 required=10.0 tests=DNS_FROM_RFC_BOGUSMX,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.82.254.195] (HELO mail200.messagelabs.com) (216.82.254.195) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Apr 2008 22:54:20 +0000 X-VirusChecked: Checked X-Env-Sender: matt.reynolds@Qsent.com X-Msg-Ref: server-8.tower-200.messagelabs.com!1207176866!5803948!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [208.252.86.23] Received: (qmail 25568 invoked from network); 2 Apr 2008 22:54:26 -0000 Received: from mail3.qsent.com (HELO corpmail1.qsent.com) (208.252.86.23) by server-8.tower-200.messagelabs.com with SMTP; 2 Apr 2008 22:54:26 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Probable "configuration" misconfiguration Date: Wed, 2 Apr 2008 15:54:30 -0700 Message-ID: <9B27A5256AC4D84DB870FEC900B8325105E83905@corpmail1.qsent.com> In-Reply-To: <635a05060802080105w624b949bmc79a3a29692a029b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Probable "configuration" misconfiguration Thread-Index: AchqMd9sR82rbfoDTvygTgsAO71/zwq4nGwA References: <9B27A5256AC4D84DB870FEC900B8325105E837D6@corpmail1.qsent.com> <635a05060802080105w624b949bmc79a3a29692a029b@mail.gmail.com> From: "Matt Reynolds" To: X-Virus-Checked: Checked by ClamAV on apache.org Alright, after much time spent not solving this problem, I have an example of what I'm seeing (Sorry about the delay). http://os.loopysoft.com/ivy/ivy.zip Run the build script (after adding your favorite version of ivy jar) and you will see the error I'm seeing where b ver 2 is somehow depending upon a version 2, *with a configuration that no longer exists*. I don't know that this is a bug, but I'd like to figure out what I'm doing wrong either way :) Thanks, and hope this helps > -----Original Message----- > From: Xavier Hanin [mailto:xavier.hanin@gmail.com] > Sent: Friday, February 08, 2008 1:06 AM > To: ivy-user@ant.apache.org > Subject: Re: Probable "configuration" misconfiguration >=20 > On Feb 7, 2008 5:03 PM, Matt Reynolds wrote: >=20 > > I apologize that this will probably be both vague and slightly wrong, > > but I don't have a way to demonstrate the problem I'm facing (I'm > open > > to suggestions on how to do so, ivy-report won't run to completion > given > > the following error). > > > > I've been using Ivy for a year or two here at work (and at home) and > > have run into an issue when I changed the available configurations > for a > > package. > > > > Let's say that we have 3 packages, A, B, C, with A depending on B and > B > > depending on C (A->B->C). We also have a package, D, that depends on > C > > and is depended upon by A (A->D->C). > > > > C has three configurations, library, server, and client, with Server > and > > Client extending Library. B and D both depend on C's "client" > > configuration. Due to a recent change, C no longer exposes the > "client" > > configuration, now only exposing the "Library" configuration. > > > > I update B with "*->library" on the C dependency, but when I attempt > to > > resolve dependencies, I get a hard error saying that C's "client" > > configuration cannot be found and so Ivy halts. This makes sense, as > D > > depends on C's configuration, and I haven't updated D. While this > > simple case is easy to fix, our real world case is not. > > > > In the real world case, we have a hierarchy about 7 levels deep, and > > changing our core library's configurations has caused cascade > failures > > throughout the dependencies in the system (a total of maybe 50 > libraries > > in total). Updating each library is not only time consuming, but in > > some cases near impossible, as older branches of code that rely on > the > > now-missing configuration can't be mixed with newer code that uses a > > different/existing configuration. > > > > I think I understand why this happens, but frankly, it's caused me to > > stop using configurations entirely and move to using exclusions where > > possible, because they're easier to maintain given the state of our > code > > base. > > > > Is there a better way to manage this? Is there a fix I'm missing? > Any > > help would be appreciated. We're very happy with Ivy for the most > part > > (we'd like to help with the docs, but we don't know enough to help > > rewrite them), but this "problem" (Ivy's fault or not) is causing us > > serious trouble. >=20 >=20 > I understand, managing complex configurations is not an easy task, and > it > needs to be well thought. Ivy supports a mechanism which helps a lot to > make > your module dependencies manageable while still using configurations > extensively: fallback configurations. This require changes in your Ivy > files > though, but it's a one time change: you do your configuration mapping > as > usual, except that you tell Ivy which configuration to pick up when the > expected configuration is not there. I suggest using something which > will > always exist as fallback configuration, which can be either a > configuration > that you ensure all your modules have ('default', or whatever), or > using a > wildcard like '*' which Ivy can always resolve. You can also use > negated > confs after the * to get all confs but some of them. >=20 > Another way to handle this is to avoid removing the conf that you don't > want > anymore in your module, and rather deprecate it, as you would do in an > API > (because module configurations should be seen as a kind of API). Then > you > can choose to publish nothing in this conf, or do whatever you want. I > personnaly prefer this solution, but the support for deprecation in Ivy > is > not very good, we have the attribute, but Ivy actually doesn't care > about > it, so you don't get information about the usage of deprecated conf. > But > this can be improved! >=20 > Xavier >=20 >=20 > > > > > > Thanks for your time, and keep up the good work, > > Matt > > >=20 >=20 >=20 > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/