As it turns out, I should have checked the dev mailing list first. I'm also getting this error : The result is an unresolved dependency: "test#b;1: configuration(s) not found in test#b;1: default. It was required from test#c;1 compile"
Although, of course, for my project. > -----Original Message----- > From: Matt Reynolds [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 07, 2008 8:04 AM > To: [EMAIL PROTECTED] > Subject: Probable "configuration" misconfiguration > > 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. > > Thanks for your time, and keep up the good work, > Matt
