After all the praises, I hope my post doesn't sound too negative. I also think it's a great addition Peter, I just have a few reservations ;-)
See below... --DD > -----Original Message----- > From: peter reilly [mailto:[EMAIL PROTECTED] > > > <presetdef> (formally known as extendtype) > this defines a new task or type based on a current ant task or type, > with attributes or elements preset. > > example useage: > <presetdef name="my.javac"> > <javac debug="${debug}" deprecation="${deprecation}"/> > </presetdef> > > <my.javac> may now be used as a task in the same way as <javac> > but the attribute debug and deprecation will be preset. I'll start by neat picking ;-) What <presetdef> does is binding a given value to a task attribute. In the C++ world, the method to do that are call bind, which is IMHO better that preset. Also, this kind of static attribute-binding is useful indeed (I've actually asked for it a few times), but is hardly a definition, and it's bad that it forces you to rewrite the task name. I don't want to modify all my builds to use <my.javac> just to take advantage of that feature. Finally, <presetdef>, in term of functionality and not implementation, is just a subset of <macrodef> in my opinion, and doesn't deserve Task status. Much more useful IMO was be the ability to bind (or preset) values using XPath expressions, to follow your example: //javac/@debug = ${debug} //javac/@deprecation = ${deprecation} To just do it for an instance of Javac inside a particular target, do //[EMAIL PROTECTED]'compile']/javac/@debug = true I've always been annoyed to having to explicitly declare a bunch of task attributes taking properties when sensible default values just to be able to maybe override them. So in conclusion, I'm +1 to the ability to bind values to task/type attributes, but without requiring task name changes, and possibly with requiring a task. I'm -0 to <presetdef> as it is. A middle ground would be to have something like this, closer to your current design: <bind-attributes> <delete quiet="true" /> <javac debug="${debug}" deprecation="${deprecation}" /> <exec failonerror="true" /> </bind-attributes> So it yields no task rename, work for any valid tasks, and is more explicit. > <macrodef> > this defines a new task in the same way as <scriptdef> except it > uses a <sequential> as a defintion of the task. The <macrodef> > task has nested elements - param and element to allow the > user to specify attributes and elements of the new task. These > get substituted into the <sequential> when the new task is > run. > > example: (from a current project) > <macrodef name="call-cc"> > <param name="target"/> > <param name="link"/> > <param name="target.dir"/> > <element name="cc-elements"/> > <sequential> > <mkdir dir="${obj.dir}/${target}"/> > <mkdir dir="${target.dir}"/> > <cc link="${link}" objdir="${obj.dir}/${target}" > outfile="${target.dir}/${target}"> > <compiler refid="compiler.options"/> > <cc-elements/> > </cc> > </sequential> > </macrodef> > > <macrodef name="compile-exec"> > <param name="program"/> > <element name="cc-files"/> > <sequential> > <call-cc target="${program}" link="executable" > target.dir="${build.bin.dir}"> > <cc-elements> > <includepath location="${gen.dir}"/> > <includepath location="test"/> > <cc-files/> > <linker refid="linker-libs"/> > </cc-elements> > </call-cc> > </sequential> > </macrodef> > > <compile-exec program="unittests"> > <cc-files> > <fileset dir="test/unittest" includes = "**/*.cpp"/> > <fileset dir="${gen.dir}" includes = "*.cpp"/> > </cc-files> > </compile-exec> <macrodef> I have much less problem with, but I concur with others that overloading the behavior of ${name} is not good. This will be confusing to me and other users that property expansion will not happen as usual at definition time, but later on. I think we need another syntax for the macro param/attributes, and keep the ${} working as usual. I propose to use either: * the XSL syntax (@name) * or a Javadoc-like syntax [EMAIL PROTECTED] name} Another advantage of the second form is that one would not need to pre-declare the macro params (making it scripting-language-like), but on the other hand, pre-declaring makes it more explicitly when reading the macro what parameters it takes. If we force pre-declaration, we can then fail on dereference to non-declared macro-param. Should param be renamed attribute? <macrodef>, from the build writer point of view, creates a new tasks, and we always speak of attributes and nested elements, not params and nesting elements. I'm -1 to <macrodef> if it keep the ${...} expansion form for params/attributes. I'm +1 to <macrodef> using nested <attribute>s and <element>s, with (@name) expansion. > > Will I place these tasks in ant or ant-contrib ? I use both, so I don't really mind ;-) Thanks Peter, --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
