I think this is fantastic work. As per Dominique's reservations, here are some observations that may make things easier.
> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > 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. > > 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. > One thing you could do here is redefine <javac> itself by doing something like: <taskdef name="orig.javac" classname="org.ant.....Javac"/> <presetdef name="javac"> <orig.javac debug="${debug}" deprecation="${deprecation}"/> </presetdef> which would realize your desired effect. This could be done internally by <presetdef/> when for example no name attribute is given. > Finally, <presetdef>, in term of functionality and not > implementation, is > just a subset of <macrodef> in my opinion, and doesn't > deserve Task status. > I disagree here, IIUC, <macrodef>'s templates must have ALL the content and parameters of the tasks inside, while <presetdef/> only sites some sort of default values. It would be interesting to know what would happen if I write: <my.javac debug="true"> ... </my.javac> would it use the value given in <presetdef> or that given in the actual task? If the later, it means that the values given in <presetdef> would be default values for the task, which sounds much better. Maybe we could rename it <defaultdef/>. :-) > 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 > This sounds like global file transformations, since you are applying the xpath all over, seems like something for a ProjectHelper like to do. > 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. > More in the middle is something like the notation I proposed above, which allows the user to decide whether he wants diferent flavours (different names) or just globally apply the change. > > > <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 really do not see what is so confusing, but +0 about it. <param/> defines a "local" property which is expanded at call time. I have always wanted Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
