ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Probable "configuration" misconfiguration
Date Fri, 08 Feb 2008 09:05:48 GMT
On Feb 7, 2008 5:03 PM, Matt Reynolds <> 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!


> Thanks for your time, and keep up the good work,
> Matt

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message