One thing you may have noticed has been my "theme" is to try and simplify everything. At the moment there is a lot of "overiding" and while it can be simple for people in the know it is a PITA for rank amateurs.
One example is available - every now and again we have added an extra test to it. Before long it could easy grow to ludicrous sizes (if you don't consider it ludicrous at the moment). So in many ways I want to step away from loose typing and into a strong typing for ant. I am not going to get into a language war but in most cases people with low technical skills are benefitted by strong typing. As one of the main audiences I have pushed ant to is web-dev guys - people who have little (or zero) knowledge of "programming" and think HTML is a prgramming language ;) Hence I really want it to be easy for them. I have already resigned myself to writing xslt sheets to convert some of the primitive forms into complex forms (ie copyfile->copy) but I would prefer if the core was as simple as possible while still maintaing power. Given that as background... At 01:54 29/3/01 +0200, Stefan Bodewig wrote: >The stuff that didn't get enough - or negative - votes in the first >pass. > >>> * Unify <available> and <uptodate> into a more general <condition> >>> task, support AND/OR of several tests here. > >Peter Donald wrote: > >> Depends on how it is done. If it is done via overloading then -1 if >> it is done by creating new tasks for each condition then +1. (Heres >> a perfect example where nested tasks work in Ants core). I would completely +1 this on this if there was some notion of stronger typing rather than overloading elements to do N differnent things. >>> * Add an <ant> task that will find build files according to a >>> * fileset and invokes a common target in them. >>> >>> * Add a JavaApply task that executes a given class with files from a >>> fileset as arguments - similar to <apply>. > >Peter Donald wrote: > >> -0 >> should be part of preprocessing Don't consider that as a veto - consider it as a "I won't support it but feel to create a .tsk to do it" ;) > >Stefan Bodewig wrote: > >> +0, well, we might need to revisit this later - maybe we don't need >> it at all as the core (or a preprocessor or whatever) would provide >> the functionality. > >------------------ > >>> * Include some more sophisticated loggers with the Ant distribution >>> * - especially for sending emails. Make the existing one more >>> * flexible (stylesheet used by XmlLogger). > >Conor MacNeill wrote: > >> +1 - This may affect the core if this is going to be specified in >> the build file and require the email message to be defined. More >> sophisticated loggers require more sophisticated configuration than >> command line options. So, does that mean I should have said -1? I think we could expose the functionality to listen for tasks either in buildfile or in some sort of config file >>> * add an attribute to <property> to read in an entire file as the >>> value of a property. > >Peter Donald wrote: > >> -1. One thing I would like to see is property/available and other similar >> tasks simplified by not overiding the tasks. Instead new tasks like >> >> <file-property ... /> >> <data-property ... /> >> <load-properties ... /> I stand by this ;) Of course this will directly be influenced by the implementation of datatypes. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
