Peter Donald <[EMAIL PROTECTED]> writes: > Who saids it won't be another fully blown language? ;) XSLT is what I > intend to use unless something better comes along. Essentially it allows > you to do as much or as little transformation on your build files as you want.
Ah, this concrete description of "templating" helps a lot. I think that this would probably address most flow control issues. > Most logic requests have been about setting values of properties, recursive > ant calls based on directories, repetition of ant targets with different > parameters etc. These can almost always be determined statically but are > done at runtime because there is as yet no templating done. Effectively > most people want to squish the functionality of autoconf, automake and make > into one process (when naturally thats a bad idea). > > My main aim is to have build files that look like the following > > <mybuild> > > <library name="jmx" version="1.2"/> > <library name="xerces" version="2.1"/> > > <product name="myjar" type="jar"> > <include name="org/apache/myjar/**" /> > </product> > > <product name="myotherjar" type="jar"> > <include name="org/apache/myotherjar/**" /> > </product> > > </mybuild> > > It would then be transformed into whatever low-level build file required > (ie all jar/javadoc/dist targets) via XSLT. [Even though this is just an exmple/suggestion] I really question your use of XSLT as the "language" of choice. My--albeit limited--experience with it has shown it to prove unwieldy for all but the simplest transformations. One viable alternative is Anakia/Velocity, which is MUCH more friendly and flexible (two attributes which I don't associate with XSLT). Daniel
