On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin <[EMAIL PROTECTED]> > wrote: > > On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart <[EMAIL PROTECTED]> > 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: http://markmail.org/message/52hqry734myzopts 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? Xavier > > > --DD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
