AW: task that allows augmentation of previously declared references
> 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: Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 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 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 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 restrict augment? Sounds reasonable. > >> > >> > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > >
Re: task that allows augmentation of previously declared references
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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 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 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 restrict augment? Sounds reasonable. >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: task that allows augmentation of previously declared references
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 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 restrict augment? Sounds reasonable. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 restrict augment? Sounds reasonable. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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: 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 > 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 . 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 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 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 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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 . 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 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 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 > 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 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-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: task that allows augmentation of previously declared references
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, 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 : >> >> >> >> >> >> 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 wrote: >> >> >>> >>> 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 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-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: task that allows augmentation of previously declared references
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 : 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 wrote: 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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 should be used carrefully. Gilles Scokart On 3 March 2010 05:52, Stefan Bodewig wrote: > 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 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-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: task that allows augmentation of previously declared references
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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 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-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: task that allows augmentation of previously declared references
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 references can be augmented. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 conjunction with 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 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-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: task that allows augmentation of previously declared references
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" 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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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, 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 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
Re: task that allows augmentation of previously declared references
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 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-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: task that allows augmentation of previously declared references
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: 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: 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: And our special extending project would redeclare: 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: Does that make sense? -Matt Gilles Scokart On 25 February 2010 05:39, 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'll just assume it's not controversial and act accordingly. ;) Thanks, Matt - 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: task that allows augmentation of previously declared references
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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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 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-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: task that allows augmentation of previously declared references
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 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 , or nested selectors to a ? 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-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: task that allows augmentation of previously declared references
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 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: task that allows augmentation of previously declared references
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'll just assume it's not > controversial and act accordingly. ;) You mean like adding path elements to a , or nested selectors to a ? 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
