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 Thu, 03 Apr 2008 14:54:39 GMT
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:xavier.hanin@gmail.com]
> Sent: Thursday, April 03, 2008 12:30 AM
> To: ivy-user@ant.apache.org
> Subject: Re: Probable "configuration" misconfiguration
> 
> 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
View raw message