ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Date Fri, 28 Mar 2008 15:31:42 GMT
On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <>

> On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin <>
> wrote:
> > On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart <>
> wrote:
> >  > +1 for me as well (let's put a little bit more presure from the Ivy
> guys ;-).
> >  >
> >  > To come back to the impact on Ivy, I think we should put a note in
> our
> >  > doc saying that using the settings task with an id requires 1.7.1.
> >
> >  We can put a reference to the bug, the problem occurs only when you
> call ant
> >  with multiple targets, each depending on the same settings, so I think
> >  people can use Ivy settings with with ant 1.7.0 without running into
> the
> >  problem.
> For the record, I think it's bad Ant style to use ids in tasks. This
> is kept around for BC, but should be discouraged. Using ids on types
> OTOH is OK, and essential to types in fact. If a task should refer to
> part of another task's internal config, this hints to the config
> needing to be its own type referred to by both tasks. It's even OK for
> the type to be implicitly created by the first task, when it receives
> for example a configid="foo" attribute, so that the second task can
> use it using configrefid="foo" or a nested <config refid="foo" />.
> I'm not sure how Ivy does it exactly, but somehow I got the feel from
> the discussions that it's using the "deprecated" id'd task pattern,
> which is a "bad" pattern IMHO. Hopefully I got the wrong feeling ;-)

I think we use that bad pattern. We've been wondering about the best form
settings should take for a while. It used to be a datatype in 2.0 alpha, but
we were running into trouble because a datatype has no lifecycle. Hence in a
discussion  Peter suggested to make it a task, using the id as we did before
for the datatype but with a default value:

This works pretty well from a user point of view who don't really know if
it's a task or datatype and don't really care. Except that we run into this
bug, and this bad pattern. So, what would you suggest? Is there something we
could do better while still preserving the behaviour we have now?


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

Xavier Hanin - Independent Java Consultant

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