ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Probable "configuration" misconfiguration
Date Thu, 03 Apr 2008 07:29:42 GMT
On Thu, Apr 3, 2008 at 12:54 AM, Matt Reynolds <matt.reynolds@qsent.com>
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:xavier.hanin@gmail.com]
> > Sent: Friday, February 08, 2008 1:06 AM
> > To: ivy-user@ant.apache.org
> > Subject: Re: Probable "configuration" misconfiguration
> >
> > On Feb 7, 2008 5:03 PM, Matt Reynolds <matt.reynolds@qsent.com> 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/

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