At 02:27 8/5/01 -0400, Jesse Tilly wrote:
>Let me start off with saying I agree with many of the design goals of Ant2.
>Vastly changing a tool midstream is tough and it appears that many of the
>enhancements and changes will not change expectations of current Ant users
>by much.
hopefully ;)
>However, implementation is another thing. I have felt for a while that Ant
>has been progressing into an XML-syntaxed scripting language with little
>checking. We already have good scripting languages and if the only goal was
>cross-platform capabilities, we could've borrowed Python/JPython. XML is a
>data description language and is ill-suited for the flow control and other
>script-like features that creep in with multiple user requests (kudos for
>refusing it in the goals).
agreed.
>One of the things that I have always imagined Ant being was a
>build-descriptor engine. Using XML, the build is *described*;
yes thats how I see it aswell.
>IOW, results based processing.
IOW?
>Peter has mentioned the use of "templating" as a sort of preprocessing of
>the antfile for setting configurations, etc. Isn't this autoconf/IMake?
>What if the templates were simple results descriptions and the transform
>created a "raw" antfile that is more like the scripting-hybrid that exists
>now. What if it really turned it into a real script!? Now we're no longer
>locked into this pseudoscript concept the antfile is now. People simply
>put:
Essentially templates are going to be used to satisfy the need where people
feel they need "scripting". So if you use/want if/while/case you should
move to templating. In the short term I am not sure this will happen
because we still don't have a autoconf stylesystem. However once we have
that in place...
Heres a sample build file descriptor that I used to prototype the ideas -
this was then transformed via xsl into a real ant build file. (see
jakarta/avalon-logkit/build.xml for sample of it's output).
--------------------------
<asl:project name="LogKit" version="0.7" hierarchy="org.apache.log.*"
group="avalon">
<!--
<asl:classpath>
</asl:classpath>
-->
<!---
<asl:jars>
</asl:jars>
-->
<asl:pre-init>
<property name="test.dir" value="${src.dir}/test"/>
<property name="compat.dir" value="${src.dir}/compat"/>
</asl:pre-init>
<asl:init>
<filter token="year" value="${year}"/>
<filter token="AVALON_BASE" value="http://jakarta.apache.org/avalon"/>
<filter token="FRAMEWORK_BASE"
value="http://jakarta.apache.org/avalon/framework"/>
</asl:init>
<asl:resources>
<check-class name="javax.servlet.ServletContext" set="servlet.present"/>
</asl:resources>
<asl:java-compile>
<src path="${test.dir}">
<exclude name="**/*" if="do.no-tests"/>
</src>
<src path="${compat.dir}"/>
<exclude name="org/apache/log/output/ServletOutputLogTarget.java"
unless="servlet.present"/>
</asl:java-compile>
<asl:style-book/>
</asl:project>
--------------------------
><app>
> <jar><package/></jar>
> <package/>
></app>
>
exactly !
>To build a jar and an open class package. Transforms and rulesets define
>what will really happen under the covers. The preprocessor turns the above
>into another file that the ant task engine understands. We could even have
>two task engines, one for Ant1 files and one for Ant2 raw files. This would
>be cross-platform and much easier to integrate into a GUI *and* allow users
>to upgrade without ditching 3-10 months worth of antfiles. Ok, that breaks
>the Ant2 goal of breaking Ant1, but it would be possible.
>
>Anyway, chew on it and let me know what you think.
+1
;)
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 |
*-----------------------------------------------------*
