> 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
contr
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
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 ti
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
th
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 ar
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
On 2010-03-23, Antoine Levy Lambert wrote:
> I prefer not to place any restriction on the 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 restri
Hi,
I prefer not to place any restriction on the 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 wrote:
On Mar 22, 2010, at 5:42 AM, Jean-Louis Boudart wrote:
On 2010-03-22, Matt Benson 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
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 easy
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
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 wrote:
> Hi,
>
> I was thinking that ant datatypes are currently de-facto mutable by default.
> Maybe we are making this too complex.
> Of course, o
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 preventi
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 :
Probably stupid, certainly not trivial to implement, but make it obvious
that's a quiet special structure that s
On 2010-03-02, Matt Benson 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
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
On 2010-02-25, Matt Benson 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 refere
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
wrote:
Did you have any example to demonstrates the benefits of such
task ?
The benefits with conjunctio
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
wrote:
Did you have any example to demonstrates the benefits of such task ?
The benefits with conjunction with could be important, in
that you can "mix-in" specializ
On Feb 25, 2010, at 1:12 PM, Gilles Scokart wrote:
On 25 February 2010 17:53, Dominique Devienne
wrote:
On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart
wrote:
Did you have any example to demonstrates the benefits of such task ?
The benefits with conjunction with could be important, i
On 25 February 2010 17:53, Dominique Devienne wrote:
> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart
> wrote:
> > Did you have any example to demonstrates the benefits of such task ?
>
> The benefits with conjunction with could be important, in
> that you can "mix-in" specialized pre-defined
On Feb 25, 2010, at 10:53 AM, Dominique Devienne wrote:
On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart
wrote:
Did you have any example to demonstrates the benefits of such task ?
The benefits with conjunction with could be important, in
that you can "mix-in" specialized pre-defined buil
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 us
On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart wrote:
> Did you have any example to demonstrates the benefits of such task ?
The benefits with conjunction with could be important, in
that you can "mix-in" specialized pre-defined builds dealing with
specific concerns (like JAXB pre-compilation
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
On Feb 25, 2010, at 8:56 AM, Dominique Devienne wrote:
On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson
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 anticipa
On Thu, Feb 25, 2010 at 8:56 AM, Dominique Devienne wrote:
> On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson 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 dis
On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson 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'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 accor
29 matches
Mail list logo
