You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jean-Louis Boudart <je...@gmail.com> on 2010/04/06 17:16:07 UTC
Augment feature
I think the idea of implementing an augment features (idea initiated by Matt
Benson as described
https://issues.apache.org/bugzilla/show_bug.cgi?id=48798or in the
previous thread) make sense.
This idea was to provide a task that allows augmentation of previously
declared references.
There is many places where it can be useful, and as far as i know nobody was
opposed on the main idea.
By the way there was one point still in discussion lost in the whole thread.
Many person was in favor of an opt-in approach to keep backward
compatibility.
I guess, you can only use <augment> feature on references that as been
designed for extention (by adding an argument like final="false" on the
reference for example).
Antoine Levy Lamber was highlighting that ant datatypes are currently
de-facto mutable by default. And maybe we were complexifying too much this
feature.
The objective of this thread is to take a decision on :
- restriction on augment feature
- and if the vote is in favor to choose one implementation design to do
it
So, What's your opinion ?
Should we introduce kind of restriction on the <augment> feature (like
"final=false") ? Or should we keep this usable on ALL existing reference ?
If the answer is yes How would you like to we restrict this ?
- by adding a new attribute (like final="false") on datatype ?
- by adding magic properties ?
- taking in consideration that taks and types are java objects, can we
reuse a java property "final" as a configuration attribute?
Exemple: private final String myProperty;
- with another alternative ?
IMHO the augment feature can live without any restriction.
As highlighted by Antoine, with current code base "reference can be modified
by user developed ant tasks or script fragments."
But, it could make sense to provide a way to make reference unmutable. Doing
this a given reference cannot be modified by <augment> task (or by any user
developped ant task / script fragment).
For example :
- if you design a target (or a datatype) used in a multithread context
you probably don't want to make it extensible (because it's gonna be a hell
to maintain).
- if you are designing kind of generic build file, you may want to have
part of this generic stuff extensible but maybe you want to restrict
extension on some of your targets/datatypes that are deeply used internally.
Part of the generic script can be kind of "blackbox".
About implementation details, i would be in favor of adding a new attribute
to datatypes (like final="true"), cause it make it easy to understand /
read.
Considering that current code base allow to modify any references and to
avoid any side effect, i suggest to make the make this restriction optional
.
I guess if you want to make a reference unmuttable you should set it
explicitly (with a final="true").
<!-- Example of an unmuttable reference -->
<myDataType id="my.reference" final="true"/>
In any case i really hope to use the <augment> feature soon in easyant :).
My 2 cents
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
Re: Augment feature
Posted by Jean-Louis Boudart <je...@gmail.com>.
Maybe you could spread the discussion in two different parts :
>
> - adding an augment task
> - adding a new attribute final to datatypes
>
+1
>
> With AspectJ it would be possible to add an attribute final and make it be
> really enforced by all tasks.
>
> I am reluctant for complex features also because I am afraid we could start
> something that we will not have the time to finish 100% and will deliver
> with bugs.
Make sense.
As the two things (augment task / final attributes on datatypes) can be
separated, maybe we could status first on the augment feature which is
really simple.
Introducing kind of final attribute on datatypes requires some larger
discutions (due to the complexity behind).
Maybe this means that there should be private references which are only
accessible within a certain scope.
If I understand well, in easyant you develop standard build files, which
> contain datatype instances with id(s)
> and you do not want your users to fiddle with these datatype instances.
> Even if there is an attribute "final", users who want to change the
> datatype instances will find a way around it.
> Unless the enforcement of final="true" is at the java runtime level (for
> instance with AspectJ).
>
Most of the time i would like to keep it flexible, easy to use and easily
extendable.
Being able to augment the fileset, etc... make sense. The <augment> task is
really appropriate here because it can strongly simplify the user experience
to adapt things to their needs.
On the other hand, in a few cases we need to provide structuring stuff, and
changing this structure requires some reflections.
So here limiting this facility by introducing kind of "final=true" make
sense.
The idea is not to lock the user and to fully restrict the access. If he
want to to change structuring things he will still be able to do it but it
will not be as simple as just as <augment>ing a datatype.
Even if we provide some stucturing stuff we should not lock the user in.
IMHO, this make particular sense in easyant but could also be applied in the
Ant context.
Regards,
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
Re: Augment feature
Posted by Antoine Levy Lambert <an...@gmx.de>.
Jean-Louis Boudart wrote:
> I think the idea of implementing an augment features (idea initiated by Matt
> Benson as described
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48798or in the
> previous thread) make sense.
> This idea was to provide a task that allows augmentation of previously
> declared references.
> There is many places where it can be useful, and as far as i know nobody was
> opposed on the main idea.
>
> By the way there was one point still in discussion lost in the whole thread.
> Many person was in favor of an opt-in approach to keep backward
> compatibility.
> I guess, you can only use <augment> feature on references that as been
> designed for extention (by adding an argument like final="false" on the
> reference for example).
>
> Antoine Levy Lamber was highlighting that ant datatypes are currently
> de-facto mutable by default. And maybe we were complexifying too much this
> feature.
>
Maybe you could spread the discussion in two different parts :
- adding an augment task
- adding a new attribute final to datatypes
With AspectJ it would be possible to add an attribute final and make it
be really enforced by all tasks.
I am reluctant for complex features also because I am afraid we could
start something that we will not have the time to finish 100% and will
deliver with bugs.
> The objective of this thread is to take a decision on :
>
> - restriction on augment feature
> - and if the vote is in favor to choose one implementation design to do
> it
>
> So, What's your opinion ?
> Should we introduce kind of restriction on the <augment> feature (like
> "final=false") ? Or should we keep this usable on ALL existing reference ?
>
>
> If the answer is yes How would you like to we restrict this ?
> - by adding a new attribute (like final="false") on datatype ?
> - by adding magic properties ?
> - taking in consideration that taks and types are java objects, can we
> reuse a java property "final" as a configuration attribute?
> Exemple: private final String myProperty;
> - with another alternative ?
>
>
> IMHO the augment feature can live without any restriction.
> As highlighted by Antoine, with current code base "reference can be modified
> by user developed ant tasks or script fragments."
>
> But, it could make sense to provide a way to make reference unmutable. Doing
> this a given reference cannot be modified by <augment> task (or by any user
> developped ant task / script fragment).
> For example :
> - if you design a target (or a datatype) used in a multithread context
> you probably don't want to make it extensible (because it's gonna be a hell
> to maintain).
> - if you are designing kind of generic build file, you may want to have
> part of this generic stuff extensible but maybe you want to restrict
> extension on some of your targets/datatypes that are deeply used internally.
> Part of the generic script can be kind of "blackbox".
>
Maybe this means that there should be private references which are only
accessible within a certain scope.
If I understand well, in easyant you develop standard build files, which
contain datatype instances with id(s)
and you do not want your users to fiddle with these datatype instances.
Even if there is an attribute "final", users who want to change the
datatype instances will find a way around it.
Unless the enforcement of final="true" is at the java runtime level (for
instance with AspectJ).
> About implementation details, i would be in favor of adding a new attribute
> to datatypes (like final="true"), cause it make it easy to understand /
> read.
>
> Considering that current code base allow to modify any references and to
> avoid any side effect, i suggest to make the make this restriction optional
> .
> I guess if you want to make a reference unmuttable you should set it
> explicitly (with a final="true").
>
> <!-- Example of an unmuttable reference -->
> <myDataType id="my.reference" final="true"/>
>
> In any case i really hope to use the <augment> feature soon in easyant :).
>
> My 2 cents
>
>
>
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Augment feature
Posted by Bruce Atherton <br...@callenish.com>.
I just wanted to let Jean Louis and Martijn know not to give up hope on
the enhancements they'd like to see.
Jean Louis, although the vote was not in favour of the final feature, it
was not against it, either. Half the community seemed to think it was a
good idea, although they didn't want to volunteer to actually implement
it. The other half didn't see the point, but neither were they blocking it.
My point is that if you were to provide an implementation in the sandbox
that optionally made references final not just for the augment feature
but also from scripting, once people could see the code a vote might
very well pass. It is easier to get a vote to adopt code to pass than to
get one that requires the creation of code from scratch.
And since many of Martijn's objections would be met with such a feature,
he might be willing to help out. Or to work on a better name for the
augment feature that could be adopted after the fact.
It is up to you guys, though.
On 08/04/2010 4:36 AM, Jean-Louis Boudart wrote:
>
>> 2. Are you in favor of an attribute that allows references to be marked
>> as final, to avoid augmentation?
>>
>>
> If both things (<augment> task and making "final" references) are separated
> i'm +1
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Augment feature
Posted by Jean-Louis Boudart <je...@gmail.com>.
My opinion is that what we really need is a VOTE thread:
>
> 1. Are you in favor of adding the augment feature to Ant?
>
Definitively +1
> 2. Are you in favor of an attribute that allows references to be marked
> as final, to avoid augmentation?
>
If both things (<augment> task and making "final" references) are separated
i'm +1
> 3. If a final attribute is decided upon, do you think it should default
> to "false"?
>
+1
As with current code base ant datatypes are currently de-facto mutable we
should keep the default value of final attribute to false.
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
Re: [Result][Vote] Augment feature
Posted by Antoine Levy Lambert <an...@gmx.de>.
Thanks for adding the task Matt,
Antoine
Matt Benson wrote:
> Thanks for conducting the vote, Bruce. The task has been added.
>
> -Matt
>
> On Apr 20, 2010, at 3:46 PM, Bruce Atherton wrote:
>
>> I lost my email server for a few days, so I can only now close the
>> vote and post the results. I believe that between my returned email
>> feed and the record of posts on MarkMail[1] I have all the results.
>> If you feel your vote was missed, let me know.
>>
>> On question 1, whether to adopt the augment feature code, we had:
>>
>> 7 votes for +1 from Jean Louis, Matt, Bruce, Stefan, Jan, Dominque,
>> Antoine
>> 1 vote for -0.5 from Martijn
>>
>> With more than 3 +1 binding votes and no -1 vetos, the motion passes.
>>
>> On question 2, whether to have a final attribute, the vote was:
>>
>> 1 votes for +1 from Jean Louis
>> 3 votes for +0 from Jan, Dominique, Antoine
>> 3 votes for -0 from Matt, Bruce, Stefan
>>
>> Without the 3 +1 binding votes required, the motion fails.
>>
>> The failure of the second question makes the third moot, but for the
>> sake of history, the result of making the final attribute defualt to
>> false was:
>>
>> 6 votes for +1 from Jean Louis, Matt, Bruce, Jan, Dominique, Antoine
>> 1 vote for +0 from Stefan
>>
>> So the augmentation feature is voted in with +7 positive votes and
>> -0.5 negative ones. The final attribute fails, and the default value
>> of the final attribute is rendered moot.
>>
>> Thanks everyone for voting.
>>
>> [1]
>> http://ant.markmail.org/search/?q=#query:%20list%3Aorg.apache.ant.dev+page:1+mid:o7hllwxqvkvru4hx+state:results
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Result][Vote] Augment feature
Posted by Matt Benson <gu...@gmail.com>.
Thanks for conducting the vote, Bruce. The task has been added.
-Matt
On Apr 20, 2010, at 3:46 PM, Bruce Atherton wrote:
> I lost my email server for a few days, so I can only now close the
> vote and post the results. I believe that between my returned email
> feed and the record of posts on MarkMail[1] I have all the results.
> If you feel your vote was missed, let me know.
>
> On question 1, whether to adopt the augment feature code, we had:
>
> 7 votes for +1 from Jean Louis, Matt, Bruce, Stefan, Jan, Dominque,
> Antoine
> 1 vote for -0.5 from Martijn
>
> With more than 3 +1 binding votes and no -1 vetos, the motion passes.
>
> On question 2, whether to have a final attribute, the vote was:
>
> 1 votes for +1 from Jean Louis
> 3 votes for +0 from Jan, Dominique, Antoine
> 3 votes for -0 from Matt, Bruce, Stefan
>
> Without the 3 +1 binding votes required, the motion fails.
>
> The failure of the second question makes the third moot, but for
> the sake of history, the result of making the final attribute
> defualt to false was:
>
> 6 votes for +1 from Jean Louis, Matt, Bruce, Jan, Dominique, Antoine
> 1 vote for +0 from Stefan
>
> So the augmentation feature is voted in with +7 positive votes and
> -0.5 negative ones. The final attribute fails, and the default
> value of the final attribute is rendered moot.
>
> Thanks everyone for voting.
>
> [1] http://ant.markmail.org/search/?q=#query:%20list%
> 3Aorg.apache.ant.dev+page:1+mid:o7hllwxqvkvru4hx+state:results
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
[Result][Vote] Augment feature
Posted by Bruce Atherton <br...@callenish.com>.
I lost my email server for a few days, so I can only now close the vote
and post the results. I believe that between my returned email feed and
the record of posts on MarkMail[1] I have all the results. If you feel
your vote was missed, let me know.
On question 1, whether to adopt the augment feature code, we had:
7 votes for +1 from Jean Louis, Matt, Bruce, Stefan, Jan, Dominque, Antoine
1 vote for -0.5 from Martijn
With more than 3 +1 binding votes and no -1 vetos, the motion passes.
On question 2, whether to have a final attribute, the vote was:
1 votes for +1 from Jean Louis
3 votes for +0 from Jan, Dominique, Antoine
3 votes for -0 from Matt, Bruce, Stefan
Without the 3 +1 binding votes required, the motion fails.
The failure of the second question makes the third moot, but for the
sake of history, the result of making the final attribute defualt to
false was:
6 votes for +1 from Jean Louis, Matt, Bruce, Jan, Dominique, Antoine
1 vote for +0 from Stefan
So the augmentation feature is voted in with +7 positive votes and -0.5
negative ones. The final attribute fails, and the default value of the
final attribute is rendered moot.
Thanks everyone for voting.
[1]
http://ant.markmail.org/search/?q=#query:%20list%3Aorg.apache.ant.dev+page:1+mid:o7hllwxqvkvru4hx+state:results
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Vote] Augment feature
Posted by Bruce Atherton <br...@callenish.com>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Vote] Augment feature
Posted by Matt Benson <gu...@gmail.com>.
Martijn,
<augment> 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 <jm...@famkruithof.net> 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 <parrallel>
> - 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 <augment> 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-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Vote] Augment feature
Posted by Martijn Kruithof <jm...@famkruithof.net>.
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 <parrallel>
- 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 <augment> 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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Vote] Augment feature
Posted by Stefan Bodewig <bo...@apache.org>.
[repeating part of my vote since I didn't vote on the third question
last time]
On 2010-04-14, Bruce Atherton <br...@callenish.com> 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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Vote] Augment feature
Posted by Antoine Levy Lambert <an...@gmx.de>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [Vote] Augment feature
Posted by Dominique Devienne <dd...@gmail.com>.
> 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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: [Vote] Augment feature
Posted by Ja...@rzf.fin-nrw.de.
> So the questions are:
>
> 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
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
[Vote] Augment feature
Posted by Bruce Atherton <br...@callenish.com>.
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?
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Augment feature
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-04-12, Matt Benson <gu...@gmail.com> wrote:
> On Apr 7, 2010, at 8:04 PM, Bruce Atherton wrote:
>> On 06/04/2010 8:16 AM, Jean-Louis Boudart wrote:
>>> The objective of this thread is to take a decision on :
>>> - restriction on augment feature
>>> - and if the vote is in favor to choose one implementation
>>> design to do
>>> it
>>> So, What's your opinion ?
>> My opinion is that what we really need is a VOTE thread:
>> 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?
Changed my opinion to -0 as well.
> Let's please consider the fact, as pointed out by Antoine, that there
> is more or less no way to prevent manipulation of references by Java
> or scripted tasks. That being the case it doesn't seem like a good
> investment of cycles to prevent this task from functioning.
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Augment feature
Posted by Jean-Louis Boudart <je...@gmail.com>.
>
>
>> Of course, if people think that this hasn't been debated enough then we
>> can continue the conversation and have the vote later.
>>
>
> Let's please consider the fact, as pointed out by Antoine, that there is
> more or less no way to prevent manipulation of references by Java or
> scripted tasks. That being the case it doesn't seem like a good investment
> of cycles to prevent this task from functioning. With my just-committed
> bugfix to RuntimeConfigurable, my current cut of AugmentReference code is
> completely self-contained which means that any third party could write the
> task and our proposed 'final' attribute would be meaningless. What might be
> doable is creating another task that would make read-only a reference by
> dynamically generating proxies that would hide setter-type (any
> parameterized?) methods, or something along those lines. _That_ could stop
> <augment> and other avenues from modifying a reference if that's really what
> we wanted. So I'd say these are separate concerns.
>
Sounds good to me
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
Re: Augment feature
Posted by Matt Benson <gu...@gmail.com>.
On Apr 7, 2010, at 8:04 PM, Bruce Atherton wrote:
> On 06/04/2010 8:16 AM, Jean-Louis Boudart wrote:
>> The objective of this thread is to take a decision on :
>>
>> - restriction on augment feature
>> - and if the vote is in favor to choose one implementation
>> design to do
>> it
>>
>> So, What's your opinion ?
>>
>
> My opinion is that what we really need is a VOTE thread:
>
> 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
>
> Of course, if people think that this hasn't been debated enough
> then we can continue the conversation and have the vote later.
Let's please consider the fact, as pointed out by Antoine, that there
is more or less no way to prevent manipulation of references by Java
or scripted tasks. That being the case it doesn't seem like a good
investment of cycles to prevent this task from functioning. With my
just-committed bugfix to RuntimeConfigurable, my current cut of
AugmentReference code is completely self-contained which means that
any third party could write the task and our proposed 'final'
attribute would be meaningless. What might be doable is creating
another task that would make read-only a reference by dynamically
generating proxies that would hide setter-type (any parameterized?)
methods, or something along those lines. _That_ could stop <augment>
and other avenues from modifying a reference if that's really what we
wanted. So I'd say these are separate concerns.
-Matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Augment feature
Posted by Bruce Atherton <br...@callenish.com>.
On 06/04/2010 8:16 AM, Jean-Louis Boudart wrote:
> The objective of this thread is to take a decision on :
>
> - restriction on augment feature
> - and if the vote is in favor to choose one implementation design to do
> it
>
> So, What's your opinion ?
>
My opinion is that what we really need is a VOTE thread:
1. Are you in favor of adding the augment feature to Ant?
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"?
Of course, if people think that this hasn't been debated enough then we
can continue the conversation and have the vote later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org