ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan.Mate...@rzf.fin-nrw.de
Subject AW: Alternatives to Ant's XML Syntax
Date Mon, 28 Jun 2004 05:50:22 GMT
Have a look at Groovy.
That language supports a nice Ant integration via its AntBuilder.

Jan


Google
http://www.google.com/search?q=groovy%20language%20ant%20builder

A short article
http://www.ftponline.com/javapro/2004_05/online/kjones_05_19_04/default_pf.a
spx

Groovy Homepage
http://groovy.codehaus.org/index.html

Ant Scripting
http://groovy.codehaus.org/ant.html
(problem: the example link
http://cvs.groovy.codehaus.org/viewcvs.cgi/groovy/groovy-core/src/test/groov
y/util/AntTest.groovy?rev=HEAD&view=auto doesnt work ...)



> -----Urspr√ľngliche Nachricht-----
> Von: Scott Sauyet [mailto:lists@sauyet.com]
> Gesendet am: Freitag, 25. Juni 2004 22:51
> An: Ant Users List
> Betreff: Alternatives to Ant's XML Syntax
> 
> (If this belongs on the dev list instead, please let me know.)
> 
> Are there any tools which accept an alternate form of syntax for Ant 
> build files?
> 
> While I love XML as an interoperable data and document 
> format, it seems 
> rather heavy for build scripts, which in my environment need 
> continual 
> tweaking.  I think that a simpler text format might make life a bit 
> easier.  I'm thinking of something like this:
> 
> ----------------------------------------------------------------------
>      target
>          name: compile
>          depends: init
>          description: Compiles all the source files into the build 
> directory.
>          javac
>              srcdir: ${java.src.dir}
>              destdir: ${build.dir}
>              debug: true
>              nowarn: true
>              classpath
>                  refid: test.classpath
>          copy
>              todir: ${build.dir}
>              fileset dir: ${java.src.dir}
>                  exclude
>                      name: **/*.java
>                  exclude
>                      name: **/*.html"
> ----------------------------------------------------------------------
> 
> (If lines wrapped, it was unintentional.)
> 
> This could be a replacement for the following:
> 
> ----------------------------------------------------------------------
>      <target name="compile"
>              depends="init"
>              description="Compiles all the source files into 
> the build 
> directory.">
>          <javac srcdir="${java.src.dir}" destdir="${build.dir}" 
> debug="true" nowarn="true">
>              <classpath refid="test.classpath"/>
>          </javac>
>          <copy todir="${build.dir}">
>              <fileset dir="${java.src.dir}">
>                  <exclude name="**/*.java"/>
>                  <exclude name="**/*.html"/>
>              </fileset>
>          </copy>
>      </target>
> ----------------------------------------------------------------------
> 
> I converted one of my moderate-sized build files to this format.  The 
> original is at http://scott.sauyet.com/ant/alt-syntax/build.xml (view 
> source if necessary) and the altered version is at 
> http://scott.sauyet.com/ant/alt-syntax/build.txt .  This 
> increases the 
> number of lines in the file significantly (by about 50% in my 
> test) but 
> does not much change the overall size of the file (decrease 
> of about 5% 
> when using tabs, increase of about 7% when using four-space indents.) 
> For me, it makes it substantially easier to read.
> 
> It would be easy to generate SAX events when parsing this file, so I 
> imagine it would be easy to connect it to Ant. But I know 
> nothing of the 
> internals of Ant; I might be missing something basic.
> 
> There seems to be one slight ambiguity in the syntax I've used, and I 
> don't know if that would justify introducing additional 
> punctuation to 
> the system:
> 
>      <element id="x">contents</element>
> 
> and
> 
>      <element id="x">
>          <contents/>
>      </element>
> 
> would both map to
> 
>      element
>          id: x
>          contents
> 
> We could disambiguate this by requiring the former one to be written
> 
>      element
>          id: x
>          : contents
> 
> But I don't really know if that is important.  Note that this 
> would not 
> work as a general XML replacement, because mixed content 
> wouldn't work, 
> but I don't think there are any cases at least in the ant core which 
> used mixed content.
> 
> My question, then, is has this been done?  Would it be 
> reasonable to do 
> so?  I know I could easily write my own parser to run ahead of Ant 
> generating the build script from this format, but it would be 
> much nicer 
> to pass a flag into Ant to signify that I'm using plain-text 
> format #7, 
> or whatever.
> 
> Any thoughts?
> 
>    -- Scott
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message