ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
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).  

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


Mime
View raw message