ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Reynolds" <matt.reyno...@Qsent.com>
Subject RE: Probable "configuration" misconfiguration
Date Wed, 02 Apr 2008 22:54:30 GMT
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 :)

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/

Mime
View raw message