You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Matt Benson <gu...@gmail.com> on 2010/02/25 05:39:48 UTC
task that allows augmentation of previously declared references
I'd like to direct the Ant developers' attention to https://
issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion. I'm
hesitant to commit this outright because I anticipate this being
somewhat controversial. If noone responds I'll just assume it's not
controversial and act accordingly. ;)
Thanks,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Peter Reilly <pe...@gmail.com>.
I agree, datatypes are mutable, properties are not, why add this complexity
of "final".
Peter
On Wed, Mar 3, 2010 at 9:13 PM, Antoine Levy Lambert <an...@gmx.de> wrote:
> Hi,
>
> I was thinking that ant datatypes are currently de-facto mutable by default.
> Maybe we are making this too complex.
> Of course, only users who can write custom tasks in java or
> javascript/groovy/... can for instance add an include pattern to an existing
> fileset, but there is nothing preventing them from doing it.
>
>
> Antoine
>
> Gilles Scokart wrote:
>>
>> I just have an idea that come into my mind. I will quickly post it (and
>> probably think it's stupid tomorow morning).
>>
>> Instead of a special id, we could maybe use a decorator :
>>
>> <mutabletype id="x">
>> <path ... />
>> </mutabletype>
>>
>> Probably stupid, certainly not trivial to implement, but make it obvious
>> that's a quiet special structure that should be used carrefully.
>>
>>
>> Gilles Scokart
>>
>>
>> On 3 March 2010 05:52, Stefan Bodewig <bo...@apache.org> wrote:
>>
>>
>>>
>>> On 2010-03-02, Matt Benson <gu...@gmail.com> wrote:
>>>
>>>
>>>>
>>>> Okay, let's reason this out... since tasks and types are Java objects
>>>> can we assume that a Java property "final" is unlikely enough to be
>>>> used that we can use it as a configuration "attribute"?
>>>>
>>>
>>> Agreed. An alternative could be anything that contains a dash or any
>>> other character that would be illegal in a Java method name (so you
>>> can't have a set-method for it).
>>>
>>>
>>>>
>>>> Now, any id'd item would declare final=false if it wanted to be
>>>> augmentable. This would require changes in the way we handle
>>>> references, but would seem doable.
>>>>
>>>
>>> +1
>>>
>>> Stefan
>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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: task that allows augmentation of previously declared references
Posted by Antoine Levy Lambert <an...@gmx.de>.
Hi,
I was thinking that ant datatypes are currently de-facto mutable by
default. Maybe we are making this too complex.
Of course, only users who can write custom tasks in java or
javascript/groovy/... can for instance add an include pattern to an
existing fileset, but there is nothing preventing them from doing it.
Antoine
Gilles Scokart wrote:
> I just have an idea that come into my mind. I will quickly post it (and
> probably think it's stupid tomorow morning).
>
> Instead of a special id, we could maybe use a decorator :
>
> <mutabletype id="x">
> <path ... />
> </mutabletype>
>
> Probably stupid, certainly not trivial to implement, but make it obvious
> that's a quiet special structure that should be used carrefully.
>
>
> Gilles Scokart
>
>
> On 3 March 2010 05:52, Stefan Bodewig <bo...@apache.org> wrote:
>
>
>> On 2010-03-02, Matt Benson <gu...@gmail.com> wrote:
>>
>>
>>> Okay, let's reason this out... since tasks and types are Java objects
>>> can we assume that a Java property "final" is unlikely enough to be
>>> used that we can use it as a configuration "attribute"?
>>>
>> Agreed. An alternative could be anything that contains a dash or any
>> other character that would be illegal in a Java method name (so you
>> can't have a set-method for it).
>>
>>
>>> Now, any id'd item would declare final=false if it wanted to be
>>> augmentable. This would require changes in the way we handle
>>> references, but would seem doable.
>>>
>> +1
>>
>> Stefan
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Gilles Scokart <gs...@gmail.com>.
I just have an idea that come into my mind. I will quickly post it (and
probably think it's stupid tomorow morning).
Instead of a special id, we could maybe use a decorator :
<mutabletype id="x">
<path ... />
</mutabletype>
Probably stupid, certainly not trivial to implement, but make it obvious
that's a quiet special structure that should be used carrefully.
Gilles Scokart
On 3 March 2010 05:52, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-03-02, Matt Benson <gu...@gmail.com> wrote:
>
> > Okay, let's reason this out... since tasks and types are Java objects
> > can we assume that a Java property "final" is unlikely enough to be
> > used that we can use it as a configuration "attribute"?
>
> Agreed. An alternative could be anything that contains a dash or any
> other character that would be illegal in a Java method name (so you
> can't have a set-method for it).
>
> > Now, any id'd item would declare final=false if it wanted to be
> > augmentable. This would require changes in the way we handle
> > references, but would seem doable.
>
> +1
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: task that allows augmentation of previously declared references
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-02, Matt Benson <gu...@gmail.com> wrote:
> Okay, let's reason this out... since tasks and types are Java objects
> can we assume that a Java property "final" is unlikely enough to be
> used that we can use it as a configuration "attribute"?
Agreed. An alternative could be anything that contains a dash or any
other character that would be illegal in a Java method name (so you
can't have a set-method for it).
> Now, any id'd item would declare final=false if it wanted to be
> augmentable. This would require changes in the way we handle
> references, but would seem doable.
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
Okay, let's reason this out... since tasks and types are Java objects
can we assume that a Java property "final" is unlikely enough to be
used that we can use it as a configuration "attribute"? Now, any
id'd item would declare final=false if it wanted to be augmentable.
This would require changes in the way we handle references, but
would seem doable.
On Mar 1, 2010, at 11:22 PM, Stefan Bodewig wrote:
> On 2010-02-25, Matt Benson <gu...@gmail.com> wrote:
>
>> I'd like to direct the Ant developers' attention to https://
>> issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.
>
> I'm with the other people in this thread who'd prefer to make this an
> option that reference have to opt-in to so that not all references can
> be augmented.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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: task that allows augmentation of previously declared references
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-02-25, Matt Benson <gu...@gmail.com> wrote:
> I'd like to direct the Ant developers' attention to https://
> issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.
I'm with the other people in this thread who'd prefer to make this an
option that reference have to opt-in to so that not all references can
be augmented.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
On Feb 25, 2010, at 10:00 AM, Gilles Scokart wrote:
> That's indeed quiet controversial. It moves ant from a declarative
> style to
> a more algorithmique language.
>
> What I dislike is that a target can have some side effect on datatype.
> Because id's are global, that will means that when you are using an
> id into
> a task, you have to look at its definition to know what it is
> about, and you
> will have to search in all other targets in all build files
> included if
> there is no augmentation of the datatype.
>
> Did you have any example to demonstrates the benefits of such task ?
>
Hi Gilles,
My recent motivation for this regards builds that are composed of
multiple files. Say I have a target in a project "jar" that creates
a jar archive:
<target name="jar">
<jar destfile="foo.jar" basedir="${classes.dir}" />
</target>
That's all well and good for many projects, but let's say we want to
always catch non-Java resources from our source directory as well.
We'd modify this to:
<target name="jar">
<jar destfile="foo.jar">
<fileset dir="${classes.dir}" />
<fileset dir="${src.dir}" excludes="**/*.java" />
</jar>
</target>
But what if we have another project that is very similar to our basic
to-be-archived-as-a-jar Java project, but has one or more extra
resource directories? We could provide a hook:
<target name="-setupJarContents" description="Set reference
jar.contents">
<resources id="jar.contents">
<fileset dir="${classes.dir}" />
<fileset dir="${src.dir}" excludes="**/*.java" />
</resources>
</target>
<target name="jar" depends="-setupJarContents">
<jar destfile="foo.jar">
<resources refid="jar.contents" />
</jar>
</target>
And our special extending project would redeclare:
<target name="-setupJarContents">
<resources id="jar.contents">
<fileset dir="${classes.dir}" />
<fileset dir="${src.dir}" excludes="**/*.java" />
<fileset dir="${resources.dir}" />
</resources>
</target>
This all works. But I am of the opinion that it is unnecessary that
we should have to repeat what was done by the parent. I'd rather
depend on jar.-setupJarContents and then somehow extend its default
notion of jar.contents . There is not a good declarative way to do
this in Ant today. My problem would be solved if I could do this:
<target name="-setupJarContents" depends="jar.-setupJarContents">
<augment id="jar.contents">
<fileset dir="${resources.dir}" />
</augment>
</target>
Does that make sense?
-Matt
> Gilles Scokart
>
>
> On 25 February 2010 05:39, Matt Benson <gu...@gmail.com> wrote:
>
>> I'd like to direct the Ant developers' attention to https://
>> issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion. I'm
>> hesitant to commit this outright because I anticipate this being
>> somewhat
>> controversial. If noone responds I'll just assume it's not
>> controversial
>> and act accordingly. ;)
>>
>> Thanks,
>> 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: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
On Feb 25, 2010, at 1:12 PM, Gilles Scokart wrote:
> On 25 February 2010 17:53, Dominique Devienne <dd...@gmail.com>
> wrote:
>
>> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gs...@gmail.com>
>> wrote:
>>> Did you have any example to demonstrates the benefits of such task ?
>>
>> The benefits with conjunction with <import> could be important, in
>> that you can "mix-in" specialized pre-defined builds dealing with
>> specific concerns (like JAXB pre-compilation for example) and have
>> those builds "implicitly" augment the classpath or Javac source path
>> appropriately for example (as documented in those builds, and you do
>> explicitly import those, so are kinda in control).
>
>
>
> This is indeed a valuable use case.
>
>
>
>> Sure, it does open
>> the door for some complexity, and Ant would enter some un-chartered
>> waters indeed, but when trying to design reusable builds in the
>> (distant now) past, I've often felt the need for such a feature. Yet
>> it doesn't necessarily mean that would have been the right solution
>> either. I'd be interesting to have the input of the EasyAnt people on
>> the matter in fact.
>
>
> Yes, that would be interresting.
>
>
>> Maybe an opt-in approach, explicitly adding
>> final="false" on those datatype ids *designed* for extension,
>> would be
>> a more conservative introduction of this feature, although that does
>> force to have "perfect hindsight" into what will be necessary to
>> extend/augment or not. --DD
>>
>>
> If we want to allow mutability, it seems indeed safer to keep
> immutability
> by default (for easier maintainability of the script).
>
> Note that there is an other benefits to immutability : it make it
> easier to
> make multithread system. The more support ant has for mutable
> datatype, the
> more complex it will be to make it multithread (and I believe
> that's one of
> the important evolution for the coming years).
>
> BTW, isn't already possible to overwrite a reference? If I
> remember well,
> it prints a warning but it replace the object.
>
My example hopefully illustrated why, while it is possible to
completely overwrite the reference, it is less than desirable to do
so, particularly if, as DD's description of pretty much my same
motivations seems to imply, you may even want to have multiple
augmentations of a given reference, e.g. when multiple components of
your build may want to contribute additional children to a reference.
-Matt
> Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Gilles Scokart <gs...@gmail.com>.
On 25 February 2010 17:53, Dominique Devienne <dd...@gmail.com> wrote:
> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gs...@gmail.com>
> wrote:
> > Did you have any example to demonstrates the benefits of such task ?
>
> The benefits with conjunction with <import> could be important, in
> that you can "mix-in" specialized pre-defined builds dealing with
> specific concerns (like JAXB pre-compilation for example) and have
> those builds "implicitly" augment the classpath or Javac source path
> appropriately for example (as documented in those builds, and you do
> explicitly import those, so are kinda in control).
This is indeed a valuable use case.
> Sure, it does open
> the door for some complexity, and Ant would enter some un-chartered
> waters indeed, but when trying to design reusable builds in the
> (distant now) past, I've often felt the need for such a feature. Yet
> it doesn't necessarily mean that would have been the right solution
> either. I'd be interesting to have the input of the EasyAnt people on
> the matter in fact.
Yes, that would be interresting.
> Maybe an opt-in approach, explicitly adding
> final="false" on those datatype ids *designed* for extension, would be
> a more conservative introduction of this feature, although that does
> force to have "perfect hindsight" into what will be necessary to
> extend/augment or not. --DD
>
>
If we want to allow mutability, it seems indeed safer to keep immutability
by default (for easier maintainability of the script).
Note that there is an other benefits to immutability : it make it easier to
make multithread system. The more support ant has for mutable datatype, the
more complex it will be to make it multithread (and I believe that's one of
the important evolution for the coming years).
BTW, isn't already possible to overwrite a reference? If I remember well,
it prints a warning but it replace the object.
Gilles Scokart
AW: task that allows augmentation of previously declared references
Posted by Ja...@rzf.fin-nrw.de.
> append/prepend isn't as far a departure from the current
> model as would be
> allowing complex expressions or arbitrary transformations.
I havent followed the discussion, but read the "append to path" and this
is possible.
You can not append directly to a path, but because paths are - in
contrast to properties - overwritable:
<macrodef name="addpath">
<attribute name="topath"/>
<element name="nested" optional="yes" implicit="true"/>
<sequential>
<path id="tmp">
<pathelement path="${toString:@{topath}}"/>
<nested/>
</path>
<path id="@{topath}"><pathelement
path="${toString:tmp}"/></path>
<path id="tmp"/>
</sequential>
</macrodef>
<addpath topath="test.classpath">
<pathelement location="${java.classes}"/>
</addpath>
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Jason Trump <tr...@gmail.com>.
Hi everybody,
Hope you don't mind a late join to the discussion.
There is some precedent for this kind of thing in Ant -- extension-points.
In fact, extension-points plus appendable paths / filesets is a potent
combination. You know:
* base script declares a few standard, empty data structures -- paths,
filesets, extension-points
* layered scripts declare contributions to each of these data structures --
add build directories to the downstream classpath, compile targets to the
"build" extension-point, etc
append/prepend isn't as far a departure from the current model as would be
allowing complex expressions or arbitrary transformations.
-jason
On Fri, Mar 26, 2010 at 1:29 AM, Gilles Scokart <gs...@gmail.com> wrote:
> I agree with your argumentation about final in java. But I'm not sure you
> can translate that to ant.
>
> First, I have access to the overwrite method in 1 key in my java IDE. In
> ant, it might be a little bit more complex.
>
> Secondly, I continue to see ant as a declarative language (although inside
> the target, the ant tasks follow an imperative style). And in a
> declarative language, it is much more unusual to overwrite/modify the
> declaration. Immutability has great value in declarative language.
>
>
> Gilles Scokart
>
>
> On 25 March 2010 23:58, Bruce Atherton <br...@callenish.com> wrote:
>
> > I agree. I see that the intent in such a final attribute is to keep a
> build
> > system understandable at a local level without worrying about what
> external
> > entities might do, but if you feel that way don't use augmentation in
> your
> > build system. The only reasons I use final keyword in programming are
> > security and performance, neither of which apply here. It is too hard to
> > predict where extensibility can prove useful to pre-empt it beforehand.
> >
> > I've tried to figure out a usecase for a final attribute, and the only
> one
> > I can think of is if you have a bunch of generic build files with the
> same
> > target names called from a master build file, and in some instances you
> want
> > the target augmented from the master build file and in some you don't.
> That
> > doesn't sound like it is very compelling for adding the attribute on the
> > first pass of the augment feature.
> >
> >
> > On 25/03/2010 9:23 AM, Stefan Bodewig wrote:
> >
> >> On 2010-03-23, Antoine Levy Lambert<an...@gmx.de> wrote:
> >>
> >>
> >>
> >>> I prefer not to place any restriction on the<augment/> feature .
> >>> In fact references currently can be modified by user developed ant
> >>> tasks or script fragments.
> >>>
> >>>
> >> So you say since references can be overridden without augment it doesn't
> >> make any sense to restrict augment? Sounds reasonable.
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
Re: task that allows augmentation of previously declared references
Posted by Bruce Atherton <br...@callenish.com>.
Point taken. But that sounds like an argument against the augment
feature itself. If you are going to make exceptions, then things aren't
really immutable at all. When properties were made immutable there had
to be ugly little hacks like the prefix on tstamp to get around the fact
there were times you really wanted a bit of mutability on the value
(though not on the meaning).
If you are going to introduce the feature, I don't see what final gets
you. But I could be convinced otherwise.
On 26/03/2010 1:29 AM, Gilles Scokart wrote:
> I agree with your argumentation about final in java. But I'm not sure you
> can translate that to ant.
>
> First, I have access to the overwrite method in 1 key in my java IDE. In
> ant, it might be a little bit more complex.
>
> Secondly, I continue to see ant as a declarative language (although inside
> the target, the ant tasks follow an imperative style). And in a
> declarative language, it is much more unusual to overwrite/modify the
> declaration. Immutability has great value in declarative language.
>
>
> Gilles Scokart
>
>
> On 25 March 2010 23:58, Bruce Atherton<br...@callenish.com> wrote:
>
>
>> I agree. I see that the intent in such a final attribute is to keep a build
>> system understandable at a local level without worrying about what external
>> entities might do, but if you feel that way don't use augmentation in your
>> build system. The only reasons I use final keyword in programming are
>> security and performance, neither of which apply here. It is too hard to
>> predict where extensibility can prove useful to pre-empt it beforehand.
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Gilles Scokart <gs...@gmail.com>.
I agree with your argumentation about final in java. But I'm not sure you
can translate that to ant.
First, I have access to the overwrite method in 1 key in my java IDE. In
ant, it might be a little bit more complex.
Secondly, I continue to see ant as a declarative language (although inside
the target, the ant tasks follow an imperative style). And in a
declarative language, it is much more unusual to overwrite/modify the
declaration. Immutability has great value in declarative language.
Gilles Scokart
On 25 March 2010 23:58, Bruce Atherton <br...@callenish.com> wrote:
> I agree. I see that the intent in such a final attribute is to keep a build
> system understandable at a local level without worrying about what external
> entities might do, but if you feel that way don't use augmentation in your
> build system. The only reasons I use final keyword in programming are
> security and performance, neither of which apply here. It is too hard to
> predict where extensibility can prove useful to pre-empt it beforehand.
>
> I've tried to figure out a usecase for a final attribute, and the only one
> I can think of is if you have a bunch of generic build files with the same
> target names called from a master build file, and in some instances you want
> the target augmented from the master build file and in some you don't. That
> doesn't sound like it is very compelling for adding the attribute on the
> first pass of the augment feature.
>
>
> On 25/03/2010 9:23 AM, Stefan Bodewig wrote:
>
>> On 2010-03-23, Antoine Levy Lambert<an...@gmx.de> wrote:
>>
>>
>>
>>> I prefer not to place any restriction on the<augment/> feature .
>>> In fact references currently can be modified by user developed ant
>>> tasks or script fragments.
>>>
>>>
>> So you say since references can be overridden without augment it doesn't
>> make any sense to restrict augment? Sounds reasonable.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: task that allows augmentation of previously declared references
Posted by Bruce Atherton <br...@callenish.com>.
I agree. I see that the intent in such a final attribute is to keep a
build system understandable at a local level without worrying about what
external entities might do, but if you feel that way don't use
augmentation in your build system. The only reasons I use final keyword
in programming are security and performance, neither of which apply
here. It is too hard to predict where extensibility can prove useful to
pre-empt it beforehand.
I've tried to figure out a usecase for a final attribute, and the only
one I can think of is if you have a bunch of generic build files with
the same target names called from a master build file, and in some
instances you want the target augmented from the master build file and
in some you don't. That doesn't sound like it is very compelling for
adding the attribute on the first pass of the augment feature.
On 25/03/2010 9:23 AM, Stefan Bodewig wrote:
> On 2010-03-23, Antoine Levy Lambert<an...@gmx.de> wrote:
>
>
>> I prefer not to place any restriction on the<augment/> feature .
>> In fact references currently can be modified by user developed ant
>> tasks or script fragments.
>>
> So you say since references can be overridden without augment it doesn't
> make any sense to restrict augment? Sounds reasonable.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Antoine Levy Lambert <an...@gmx.de>.
> So you say since references can be overridden without augment it doesn't
> make any sense to restrict augment? Sounds reasonable.
>
Yes. An attribute "final" on datatypes would make sense, if datatypes
were internally changed, so that any calls to setters, add methods, ...
after having defined them with an id and final="true", results in a run
time exception.
> Stefan
>
>
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-23, Antoine Levy Lambert <an...@gmx.de> wrote:
> I prefer not to place any restriction on the <augment/> feature .
> In fact references currently can be modified by user developed ant
> tasks or script fragments.
So you say since references can be overridden without augment it doesn't
make any sense to restrict augment? Sounds reasonable.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Antoine Levy Lambert <an...@gmx.de>.
Hi,
I prefer not to place any restriction on the <augment/> feature .
In fact references currently can be modified by user developed ant tasks
or script fragments.
Regards,
Antoine
Stefan Bodewig wrote:
> On 2010-03-22, Matt Benson <gu...@gmail.com> wrote:
>
>
>> On Mar 22, 2010, at 5:42 AM, Jean-Louis Boudart wrote:
>>
>
>
>>> Is the augment feature already commited on trunk (i've not checked
>>> the trunk for a while)? Is it targeted to be in the 1.8.1?
>>>
>
>
>> It depends on the timeframe for 1.8.1. I haven't been able to clearly
>> gauge the general direction of majority opinion on the "final" issue.
>>
>
> I may be unable to gauge my own opinion on the "final" issue 8-)
>
> AFAIR I initially supported making references explicitly opt-in and
> can't remember the cons at all (yes, I could search the archives).
>
> Maybe we should open that thread again so arguments can be made again
> and not get lost in the "do we want the task" discussion.
>
> Stefan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-22, Matt Benson <gu...@gmail.com> wrote:
> On Mar 22, 2010, at 5:42 AM, Jean-Louis Boudart wrote:
>> Is the augment feature already commited on trunk (i've not checked
>> the trunk for a while)? Is it targeted to be in the 1.8.1?
> It depends on the timeframe for 1.8.1. I haven't been able to clearly
> gauge the general direction of majority opinion on the "final" issue.
I may be unable to gauge my own opinion on the "final" issue 8-)
AFAIR I initially supported making references explicitly opt-in and
can't remember the cons at all (yes, I could search the archives).
Maybe we should open that thread again so arguments can be made again
and not get lost in the "do we want the task" discussion.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
On Mar 22, 2010, at 5:42 AM, Jean-Louis Boudart wrote:
> Sorry for the delay.
>
> I really like the idea of being able to "augment" previously declared
> reference. There is many uses cases where it can be useful.
> For example, if ant can provides such feature it would simplify a
> lot the
> job in easyant for projects using many directories as source folder.
> They will just need to augment the fileset used for source folder.
>
> It makes also senses for other dataType.
>
> I'm also +1 for the "final=false" attribute.
>
> By the way i think the only use case that is discutable is for
> <path>. Most
> of the time we want to append something to an existing classpath,
> so here
> augment make sense. But how will the augment feature will help us
> if we want
> to prepend things in the classpath (for example if we use coverage
> tools,
> instrumented classes must be put before the compiled classes in the
> classpath)?
> In EasyAnt we've defined our own <path> task that handle this use
> cases
> (allowing prepend / append / overwrite).
> Considering that this problem cannot be solved just by using "augment"
> feature, should we improve the behavior of <path> task? or let each
> projects
> defined their own task to do this?
>
> Is the augment feature already commited on trunk (i've not checked
> the trunk
> for a while)? Is it targeted to be in the 1.8.1?
>
It depends on the timeframe for 1.8.1. I haven't been able to
clearly gauge the general direction of majority opinion on the
"final" issue.
-Matt
> My 2 cents
>
>
>
>
> 2010/2/25 Dominique Devienne <dd...@gmail.com>
>
>> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gs...@gmail.com>
>> wrote:
>>> Did you have any example to demonstrates the benefits of such task ?
>>
>> The benefits with conjunction with <import> could be important, in
>> that you can "mix-in" specialized pre-defined builds dealing with
>> specific concerns (like JAXB pre-compilation for example) and have
>> those builds "implicitly" augment the classpath or Javac source path
>> appropriately for example (as documented in those builds, and you do
>> explicitly import those, so are kinda in control). Sure, it does open
>> the door for some complexity, and Ant would enter some un-chartered
>> waters indeed, but when trying to design reusable builds in the
>> (distant now) past, I've often felt the need for such a feature. Yet
>> it doesn't necessarily mean that would have been the right solution
>> either. I'd be interesting to have the input of the EasyAnt people on
>> the matter in fact. Maybe an opt-in approach, explicitly adding
>> final="false" on those datatype ids *designed* for extension,
>> would be
>> a more conservative introduction of this feature, although that does
>> force to have "perfect hindsight" into what will be necessary to
>> extend/augment or not. --DD
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Project Lead http://www.easyant.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Jean-Louis Boudart <je...@gmail.com>.
Sorry for the delay.
I really like the idea of being able to "augment" previously declared
reference. There is many uses cases where it can be useful.
For example, if ant can provides such feature it would simplify a lot the
job in easyant for projects using many directories as source folder.
They will just need to augment the fileset used for source folder.
It makes also senses for other dataType.
I'm also +1 for the "final=false" attribute.
By the way i think the only use case that is discutable is for <path>. Most
of the time we want to append something to an existing classpath, so here
augment make sense. But how will the augment feature will help us if we want
to prepend things in the classpath (for example if we use coverage tools,
instrumented classes must be put before the compiled classes in the
classpath)?
In EasyAnt we've defined our own <path> task that handle this use cases
(allowing prepend / append / overwrite).
Considering that this problem cannot be solved just by using "augment"
feature, should we improve the behavior of <path> task? or let each projects
defined their own task to do this?
Is the augment feature already commited on trunk (i've not checked the trunk
for a while)? Is it targeted to be in the 1.8.1?
My 2 cents
2010/2/25 Dominique Devienne <dd...@gmail.com>
> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gs...@gmail.com>
> wrote:
> > Did you have any example to demonstrates the benefits of such task ?
>
> The benefits with conjunction with <import> could be important, in
> that you can "mix-in" specialized pre-defined builds dealing with
> specific concerns (like JAXB pre-compilation for example) and have
> those builds "implicitly" augment the classpath or Javac source path
> appropriately for example (as documented in those builds, and you do
> explicitly import those, so are kinda in control). Sure, it does open
> the door for some complexity, and Ant would enter some un-chartered
> waters indeed, but when trying to design reusable builds in the
> (distant now) past, I've often felt the need for such a feature. Yet
> it doesn't necessarily mean that would have been the right solution
> either. I'd be interesting to have the input of the EasyAnt people on
> the matter in fact. Maybe an opt-in approach, explicitly adding
> final="false" on those datatype ids *designed* for extension, would be
> a more conservative introduction of this feature, although that does
> force to have "perfect hindsight" into what will be necessary to
> extend/augment or not. --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
Re: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
On Feb 25, 2010, at 1:55 PM, Antoine Levy Lambert wrote:
> Matt Benson wrote:
>>
>> On Feb 25, 2010, at 10:53 AM, Dominique Devienne wrote:
>>
>>> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart
>>> <gs...@gmail.com> wrote:
>>>> Did you have any example to demonstrates the benefits of such
>>>> task ?
>>>
>>> The benefits with conjunction with <import> could be important, in
>>> that you can "mix-in" specialized pre-defined builds dealing with
>>> specific concerns (like JAXB pre-compilation for example) and have
>>> those builds "implicitly" augment the classpath or Javac source path
>>> appropriately for example (as documented in those builds, and you do
>>> explicitly import those, so are kinda in control). Sure, it does
>>> open
>>> the door for some complexity, and Ant would enter some un-chartered
>>> waters indeed, but when trying to design reusable builds in the
>>> (distant now) past, I've often felt the need for such a feature. Yet
>>> it doesn't necessarily mean that would have been the right solution
>>> either. I'd be interesting to have the input of the EasyAnt
>>> people on
>>> the matter in fact. Maybe an opt-in approach, explicitly adding
>>> final="false" on those datatype ids *designed* for extension,
>>> would be
>>
>> I could live with this. :) We could also include a magic
>> property for the default.
> I do not like very much magic properties. I think we would be fine
> if by default all datatypes instances can be augmented. In fact
> they can already by special tasks or scripting. Adding a new
> attribute final on datatypes allowing users to write
>
> <fileset id="myunmodifiablefileset" final="true" dir="foo/bar">
> <include name="special.txt"/>
> </fileset>
>
> would be fine.
>
In the vein of discussing whether we have some notion of declaring
that a given reference cannot be augmented, and thus granting some
degree of "specialness" to this task, I also note a test failure that
I didn't originally understand was mine with my local change to
RuntimeConfigurable. If AugmentReference is special, then
RuntimeConfigurable can explicitly know about it and the broken test
situation goes away. :)
-Matt
> Regards,
>
> Antoine
>> Having the augmentation feature supported at such a low level
>> would help establish its specialness, which is most evident in its
>> (ab)use of the id attribute, which decision I must stand by,
>> however, since this is the only attribute we should be guaranteed
>> not to need to modify on the original referenced object.
>>
>> -Matt
>>
>>> a more conservative introduction of this feature, although that does
>>> force to have "perfect hindsight" into what will be necessary to
>>> extend/augment or not. --DD
>>>
>
>
> ---------------------------------------------------------------------
> 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: task that allows augmentation of previously declared references
Posted by Antoine Levy Lambert <an...@gmx.de>.
Matt Benson wrote:
>
> On Feb 25, 2010, at 10:53 AM, Dominique Devienne wrote:
>
>> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gs...@gmail.com>
>> wrote:
>>> Did you have any example to demonstrates the benefits of such task ?
>>
>> The benefits with conjunction with <import> could be important, in
>> that you can "mix-in" specialized pre-defined builds dealing with
>> specific concerns (like JAXB pre-compilation for example) and have
>> those builds "implicitly" augment the classpath or Javac source path
>> appropriately for example (as documented in those builds, and you do
>> explicitly import those, so are kinda in control). Sure, it does open
>> the door for some complexity, and Ant would enter some un-chartered
>> waters indeed, but when trying to design reusable builds in the
>> (distant now) past, I've often felt the need for such a feature. Yet
>> it doesn't necessarily mean that would have been the right solution
>> either. I'd be interesting to have the input of the EasyAnt people on
>> the matter in fact. Maybe an opt-in approach, explicitly adding
>> final="false" on those datatype ids *designed* for extension, would be
>
> I could live with this. :) We could also include a magic property
> for the default.
I do not like very much magic properties. I think we would be fine if by
default all datatypes instances can be augmented. In fact they can
already by special tasks or scripting. Adding a new attribute final on
datatypes allowing users to write
<fileset id="myunmodifiablefileset" final="true" dir="foo/bar">
<include name="special.txt"/>
</fileset>
would be fine.
Regards,
Antoine
> Having the augmentation feature supported at such a low level would
> help establish its specialness, which is most evident in its (ab)use
> of the id attribute, which decision I must stand by, however, since
> this is the only attribute we should be guaranteed not to need to
> modify on the original referenced object.
>
> -Matt
>
>> a more conservative introduction of this feature, although that does
>> force to have "perfect hindsight" into what will be necessary to
>> extend/augment or not. --DD
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
On Feb 25, 2010, at 10:53 AM, Dominique Devienne wrote:
> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart
> <gs...@gmail.com> wrote:
>> Did you have any example to demonstrates the benefits of such task ?
>
> The benefits with conjunction with <import> could be important, in
> that you can "mix-in" specialized pre-defined builds dealing with
> specific concerns (like JAXB pre-compilation for example) and have
> those builds "implicitly" augment the classpath or Javac source path
> appropriately for example (as documented in those builds, and you do
> explicitly import those, so are kinda in control). Sure, it does open
> the door for some complexity, and Ant would enter some un-chartered
> waters indeed, but when trying to design reusable builds in the
> (distant now) past, I've often felt the need for such a feature. Yet
> it doesn't necessarily mean that would have been the right solution
> either. I'd be interesting to have the input of the EasyAnt people on
> the matter in fact. Maybe an opt-in approach, explicitly adding
> final="false" on those datatype ids *designed* for extension, would be
I could live with this. :) We could also include a magic property
for the default. Having the augmentation feature supported at such a
low level would help establish its specialness, which is most evident
in its (ab)use of the id attribute, which decision I must stand by,
however, since this is the only attribute we should be guaranteed not
to need to modify on the original referenced object.
-Matt
> a more conservative introduction of this feature, although that does
> force to have "perfect hindsight" into what will be necessary to
> extend/augment or not. --DD
>
> ---------------------------------------------------------------------
> 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: task that allows augmentation of previously declared references
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gs...@gmail.com> wrote:
> Did you have any example to demonstrates the benefits of such task ?
The benefits with conjunction with <import> could be important, in
that you can "mix-in" specialized pre-defined builds dealing with
specific concerns (like JAXB pre-compilation for example) and have
those builds "implicitly" augment the classpath or Javac source path
appropriately for example (as documented in those builds, and you do
explicitly import those, so are kinda in control). Sure, it does open
the door for some complexity, and Ant would enter some un-chartered
waters indeed, but when trying to design reusable builds in the
(distant now) past, I've often felt the need for such a feature. Yet
it doesn't necessarily mean that would have been the right solution
either. I'd be interesting to have the input of the EasyAnt people on
the matter in fact. Maybe an opt-in approach, explicitly adding
final="false" on those datatype ids *designed* for extension, would be
a more conservative introduction of this feature, although that does
force to have "perfect hindsight" into what will be necessary to
extend/augment or not. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Gilles Scokart <gs...@gmail.com>.
That's indeed quiet controversial. It moves ant from a declarative style to
a more algorithmique language.
What I dislike is that a target can have some side effect on datatype.
Because id's are global, that will means that when you are using an id into
a task, you have to look at its definition to know what it is about, and you
will have to search in all other targets in all build files included if
there is no augmentation of the datatype.
Did you have any example to demonstrates the benefits of such task ?
Gilles Scokart
On 25 February 2010 05:39, Matt Benson <gu...@gmail.com> wrote:
> I'd like to direct the Ant developers' attention to https://
> issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion. I'm
> hesitant to commit this outright because I anticipate this being somewhat
> controversial. If noone responds I'll just assume it's not controversial
> and act accordingly. ;)
>
> Thanks,
> Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: task that allows augmentation of previously declared references
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Feb 25, 2010 at 8:56 AM, Dominique Devienne <dd...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson <gu...@gmail.com> wrote:
>> I'd like to direct the Ant developers' attention to
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.
BTW, I think the list is a better place for the discussion to take
place in, rather that BugZilla, which can be used as support for the
email thread. My $0.02. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: task that allows augmentation of previously declared references
Posted by Matt Benson <gu...@gmail.com>.
On Feb 25, 2010, at 8:56 AM, Dominique Devienne wrote:
> On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson
> <gu...@gmail.com> wrote:
>> I'd like to direct the Ant developers' attention to
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=48798 for
>> discussion.
>> I'm hesitant to commit this outright because I anticipate this being
>> somewhat controversial. If noone responds I'll just assume it's not
>> controversial and act accordingly. ;)
>
> You mean like adding path elements to a <path>, or nested selectors to
> a <selector>? That would be useful indeed.
>
Yes, hence my chronic desire for it. ;)
> If attributes can be changed as well, that's not aumentation anymore,
> but editing, no?
True. But changing attributes and adding elements are easy.
Complete editing, including *removing* elements is another thing
entirely... :|
> Can only "top-level" elements be augmented, or id'd nested elements
> as well?
This approach should work for any reference; I'll add a test.
> Can one "prevent" augmentation while still having an id attribute?
> (like final="true")
Hmm, interesting idea.
>
> Stefan would like to see the code, but I'd like to see build snippets
> from the "user" side of it ;) --DD
>
My patch includes some basic tests. It's really about as simple as
it could be, IMO.
WRT your other mail, I'm fine for discussion to take place here, so
long as it takes place. ;P
-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: task that allows augmentation of previously declared references
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson <gu...@gmail.com> wrote:
> I'd like to direct the Ant developers' attention to
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.
> I'm hesitant to commit this outright because I anticipate this being
> somewhat controversial. If noone responds I'll just assume it's not
> controversial and act accordingly. ;)
You mean like adding path elements to a <path>, or nested selectors to
a <selector>? That would be useful indeed.
If attributes can be changed as well, that's not aumentation anymore,
but editing, no?
Can only "top-level" elements be augmented, or id'd nested elements as well?
Can one "prevent" augmentation while still having an id attribute?
(like final="true")
Stefan would like to see the code, but I'd like to see build snippets
from the "user" side of it ;) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org