ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Reynolds" <>
Subject RE: Probable "configuration" misconfiguration
Date Thu, 07 Feb 2008 20:37:20 GMT
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 []
> Sent: Thursday, February 07, 2008 8:04 AM
> To:
> 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
> depending on C (A->B->C).  We also have a package, D, that depends on
> 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
> resolve dependencies, I get a hard error saying that C's "client"
> configuration cannot be found and so Ivy halts.  This makes sense, as
> 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?
> help would be appreciated.  We're very happy with Ivy for the most
> (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

View raw message