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
