Added. Is there any traction on this (I could compile from trunk?), or a hint on how to fix it? Unfortunately, this is causing us some trouble.
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 03, 2008 12:30 AM > To: [email protected] > Subject: Re: Probable "configuration" misconfiguration > > On Thu, Apr 3, 2008 at 12:54 AM, Matt Reynolds > <[EMAIL PROTECTED]> > wrote: > > > 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 :) > > This is a bug, related to IVY-681. To be sure it gets fixed, please > open an > issue and attach your zip, so that we close the issue only when your > example > passes. BTW, in your example you can remove the unused targets ivy- > configure > and ivy-fetch-dependencies, and make build-publish the default, to make > it > easier to run the test. > > Xavier > > > > > > 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/ > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/
