ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Ivy svn breaks ant-contrib svn
Date Thu, 17 Jul 2008 09:24:41 GMT
On Thu, Jul 17, 2008 at 10:00 AM, Stefan Bodewig <> wrote:

> On Wed, 16 Jul 2008, Xavier Hanin <> wrote:
> > Yes, I think setSettingsId is the good method to call, 2.0.0-beta2 was
> > broken in that sense. Introducing a setId method for backward
> compatiblity
> > with something broken in concept doesn't sound really nice IMO. We will
> > probably forget to remove it after, I don't like it too much. IMO
> antcontrib
> > should be built either against trunk, or against beta2, but not both.
> >
> > But maybe others have a different opinion?
> This is exactly the kind of change that Gump was designed to catch and
> I'm glad it did.  I don't really have an opinion on the particular
> change but am a strong proponent of not breaking APIs in general (at
> least not without a deprecation period).

I agree in general, but Ivy 2 has been going in a deep code change, and we
decided to keep backward compatibility with 1.4 at ant tasks level, but not
at API level. We warned the users about that in the release notes, and
changing code in Ivy for backward compatibility with a beta  version (which
in Ivy language is not a release candidate) sounds not like a good idea to
me. But once again I'm alone to decide, and if more people think it makes
sense, I won't object.

> Right now ant-contrib doesn't have anything but beta2 to build
> against, so it must use setId.


>  Once the next Ivy release is available
> they (we, sometimes it's hard to wear different hats) can switch to
> setSettingsId - or more precisely must.  This forces ant-contrib to
> lock step its release plan with Ivy's - if there was such a plan.

Yes, in a way. That's the problem of using a beta version as a dependency.
And that's also a problem of long release cycles, I'd really like to get Ivy
2 final released asap to avoid or at least reduce this kind of problem in
the future.

> I'd avoid using reflection and in this particular case don't really
> care too much, so I will simply keep Gump broken until Ivy has a new
> artifact ant-contrib can build against.  It may be something you
> should keep in mind when preparing the release notes of the next Ivy
> release, though.

This sounds like a good option.


> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

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