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:[EMAIL PROTECTED] > Sent: Friday, February 08, 2008 1:06 AM > To: [email protected] > Subject: Re: Probable "configuration" misconfiguration > > On Feb 7, 2008 5:03 PM, Matt Reynolds <[EMAIL PROTECTED]> wrote: > > > 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. > > > 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. > > 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! > > Xavier > > > > > > > > Thanks for your time, and keep up the good work, > > Matt > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/
