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 15:03:48 GMT
On Thu, Apr 3, 2008 at 4:54 PM, Matt Reynolds <matt.reynolds@qsent.com>
wrote:

> 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.

Unfortunately, this is not fixed yet, and pretty difficult to fix on your
own if you don't have a good knowledge of Ivy internals. Indeed, sometimes
sharing configuration mapping between evicted and selected revision makes
sense, that's why it has been introduced. So we can't simply remove this
sharing, we need to implement something smart enough to deal with all the
cases.

As a workaround, you can still use fallback configurations.

Xavier

>
>
> > -----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/
>



-- 
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