ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Peter's ANT2 design proposals
Date Tue, 08 May 2001 22:24:38 GMT
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).  


>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.


>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

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.*"


    <property name="test.dir" value="${src.dir}/test"/>
    <property name="compat.dir" value="${src.dir}/compat"/>

    <filter token="year" value="${year}"/>
    <filter token="AVALON_BASE" value=""/>
    <filter token="FRAMEWORK_BASE"

    <check-class name="javax.servlet.ServletContext" set="servlet.present"/>

    <src path="${test.dir}">
      <exclude name="**/*" if=""/>    
    <src path="${compat.dir}"/>
    <exclude name="org/apache/log/output/"



>  <jar><package/></jar>
>  <package/>

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.  





| "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               |

View raw message