Patrick Beard wrote: > >Below is a simple task that increments a numeric property in a java property > >file. > > This does seem like a perfect task that could be defined using a > script, such as a JavaScript that uses a Properties object, reads a > properties file, increments a value, and then writes it back out in a > file. > > Let's make script tasks a priority.
My 2 cents: script tasks are great; but I would hate to see support for common build needs pushed out of Ant just because a script task can do it. If common build setups require using scripts, then two of Ant's major strengths, simplicity of _use_ and portability, have been compromised: Simplicity of use*, because if the build instructions for typical projects begin with "install Ant _and_ scripting app XYZ", even installing isn't so simple. Needing to learn yet another language just to understand the build file makes it even less simple. I'd really rather go read a real Ant task: I already know Java. Portability, because a build file that requires scripting is only as portable as the scripting application. I'd argue that projects that really want the simplicity and portability benefits of Ant should not use scripting. If they need something that Ant doesn't support, they should provide an appropriate Ant task. For common requirements, it would be a shame not to provide a standard task, or at least a standard "optional" task. On a slightly different tangent, it has occurred to me while watching the "case" task debate that if enough people need an "optional" task, it will become a de facto standard. Louis Tribble * "Simplicity of use" is not necessarily the same as "simplicity of Ant"! With respect to the above points, Ant could win the simplicity battle but lose the war. P.S. Kudos to those who have stepped forward to pick up the slack in the last few months. Regardless of the particulars of these issues, Ant is a great tool.
