Steve Loughran recently posted Meeting new challenges with Ant1.7 [PDF], a presentation he made at ApacheCon Europe 2005. In this he talks about existing features in Ant1.6.x being refined and new features being introduced in Ant1.7. An intresting observation is about (in)suitablity of Ant for deployment and mention of a little known opensource software SmartFrog.
Here is a brief summary for the impatient (but you must go through the presentation to make sense of any of this):
- presetdef task for declaring new default values for existing tasks.
- macrodef for defining new tasks.
- more 'tasks' for embedding scripts.
- improved visibility into 'imported' files.
- Ant is not a good deployment engine. Use SmartFrog instead!
- support for Java 1.5 -- apt task, "1.5" value for "source" and "target" attributes in javac task, etc.
After going through the presentation, I couldn't help myself from thinking:
- With presetdef, macrodef and support for various embedded scripts, Ant seems to be evolving into a full-fledged programming environment. I can understand the need for these additional features to support modularity and reuse, but only when Ant is the driver. As I have shown in my Supercharging Beanshell with Ant paper, it is possible to use Ant from within a scripting engine, and not require tags like presetdef and macrodef (you could simply create corresponding scripted objects with appropriate attribute values and reuse them).
- I can't use presetdef to override the defaults used in sub-project level build files in my master build file. More specifically, I cannot have "javac" task without "debug" attribute with a property (as in <javac debug=${debug_flag} .../>) and hope to do a build through a master build file with debug enabled for testing and debug disabled for production. This is something that I feel Ant should support.
Comments (1)
Pankaj,
You can have <javac> and <presetdef> do what you describe in the last paragraph ("More specifically, I cannot have "javac" task...") like this:
<target name="-init" description="Initialzes the needed properties"> <property name="javac.debug" value="true"/> <property name="javac.debuglevel" value="vars,lines,source"/> <property name="javac.deprecation" value="true"/> <presetdef name="javac"> <javac debug="${javac.debug}" debuglevel="${javac.debuglevel}" deprecation="${javac.deprecation}"/> </presetdef> ... </target><target name="compile" depends="-init">
<javac ...>
<!-- Uses javac defined in -init -->
</target>
<target name="-prod.init"
description="Initialzes the needed properties used for making a build for production">
<property name="javac.debug" value="false"/>
<property name="javac.deprecation"
value="false"/>
...
</target>
<target name="prod" depends="-prod.init,compile"
description="Creates a build for production">
...
</target>
When you execute prod target, it will first execute -prod.init, which will set the debug-controlling properties. Next, it will execute -init, which will *not* override the debug-controlling properties and so will be <presetdef>ed with debug off and will compile the sources with no debug info. However, when you call compile directly, <javac> will be <presetdef>ed with debug on.
So you can have <javac> behave differenly for the differen targets.
Regards Ivan
Posted by Ivan Ivanov | August 9, 2005 8:32 AM
Posted on August 9, 2005 08:32