Re: [Vote] Augment feature
On 13/04/2010 3:34 PM, Bruce Atherton wrote: 1. Are you in favor of adding the augment feature to Ant? +1 2. Are you in favor of an attribute that allows references to be marked as final, to avoid augmentation? -0 3. If a final attribute is decided upon, do you think it should default to "false"? +1 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Vote] Augment feature
[repeating part of my vote since I didn't vote on the third question last time] On 2010-04-14, Bruce Atherton wrote: > 1. Are you in favor of adding the augment feature to Ant? +1 > 2. Are you in favor of an attribute that allows references to be > marked as final, to avoid augmentation? -0 > 3. If a final attribute is decided upon, do you think it should > default to "false"? +0 Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Vote] Augment feature
> 1. Are you in favor of adding the augment feature to Ant? +1 > 2. Are you in favor of an attribute that allows references to >be marked as final, to avoid augmentation? +0 > 3. If a final attribute is decided upon, do you think it >should default to "false"? +1 --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Vote] Augment feature
Same here Dominique Devienne wrote: 1. Are you in favor of adding the augment feature to Ant? +1 2. Are you in favor of an attribute that allows references to be marked as final, to avoid augmentation? +0 3. If a final attribute is decided upon, do you think it should default to "false"? +1 Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Vote] Augment feature
Hello I have quite some difficulties with the discrepancy of the name of the task and that what the task is about to do. Therefore, using the current name and functionality I would cast a -0,5 vote, as i do not want to be blocking. I can see the desire for a task that changes predeclared id's. My objection against the current name comes from the fact that the task not only augments (basically adds, increases, stretches, enlarges etc.) things but it is used to change the path at will. On the other hand I think free modification of references seems like a giant pitfall in the following situations: - when used in combination with - when related tasks in a script expect the same elements present on the path If the augment task was used to do only what its name implies (extend) and not to reduce less problems could be expected. Therefore I would be in favour of an feature if it can only be used to augment (and not change at will). On 14-4-2010 0:34, Bruce Atherton wrote: Ok, so this didn't start out as a vote thread, just my suggestion for what questions should appear in the vote. But since it has morphed into that I've changed the subject line to make it easier for people to find. So the questions are: 1. Are you in favor of adding the augment feature to Ant? -0,5 : Non blocking negative look. +1 if augment is only used to augment (increase, extend, combine, add to the existing) 2. Are you in favor of an attribute that allows references to be marked as final, to avoid augmentation? 3. If a final attribute is decided upon, do you think it should default to "false"? If you have already voted, no need to recast your vote. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Vote] Augment feature
Martijn, can change properties that are coded as attributes, but only interacts with nested elements by adding new children to a given reference. The task as it stands is extremely, extremely simple. Any restrictions we care to impose would complicate it immensely--I would again urge that we consider addressing this universally for all "attack vectors" by creating a task to "armor" a reference. In my copious spare time (ha) I may start a sandbox antlib for that purpose. Thanks for not wanting to be a blocker. :) -Matt On 4/18/10, Martijn Kruithof wrote: > Hello > > I have quite some difficulties with the discrepancy of the name of the > task and that what the task is about to do. > Therefore, using the current name and functionality I would cast a -0,5 > vote, as i do not want to be blocking. > I can see the desire for a task that changes predeclared id's. > > My objection against the current name comes from the fact that the task > not only augments (basically adds, increases, stretches, enlarges etc.) > things but it is used to change the path at will. > > On the other hand I think free modification of references seems like a > giant pitfall in the following situations: > - when used in combination with > - when related tasks in a script expect the same elements present on > the path > > If the augment task was used to do only what its name implies (extend) > and not to reduce less problems could be expected. > Therefore I would be in favour of an feature if it can only be > used to augment (and not change at will). > > > On 14-4-2010 0:34, Bruce Atherton wrote: >> Ok, so this didn't start out as a vote thread, just my suggestion for >> what questions should appear in the vote. But since it has morphed >> into that I've changed the subject line to make it easier for people >> to find. So the questions are: >> >> 1. Are you in favor of adding the augment feature to Ant? >> > -0,5 : Non blocking negative look. +1 if augment is only used to augment > (increase, extend, combine, add to the existing) > >> 2. Are you in favor of an attribute that allows references to be >> marked as final, to avoid augmentation? >> >> 3. If a final attribute is decided upon, do you think it should >> default to "false"? >> >> If you have already voted, no need to recast your vote. >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
