Peter Donald wrote:
At 11:20 PM 7/11/2002 -0500, you wrote:
I thought the idea was that ant2 will have those famous incompatible API/
build.xml changes ( or will just be the next release after 1.9 :-).
Running existing Ant 1.x build files with Ant 2 could be implemented by a) recognizing the document is not using the Ant 2 namespace, b) piping the content through an XSLT processor. No need to add a lot of code to support backward compatibility. Hopefully, the syntax will be close enough that the transform would be fairly simple. It would also give people a tool to convert an Ant 1.x build file to Ant 2 build file.
That was the initial plan I believe. However in prototyping this it was found that it was easier to add special code to handle the differences. Along with the syntactical differences of ant1.x to ant2 there is also slightly semantic changes and unless you are aware of these changes your build wont work anyways. Consider the following;
<project ...>
<path id="x" dir="."> <pathelement location="nonexistant/file.txt"/> </path>
<target name="X"> </target>
<target name="Y"> <property name="x.prop" refid="x"/> <echo message="x=${x.prop}"/> </target>
</project>
In Ant1.x you could run target X fine. However if you tried to run Y it would generate a
"Error: nonexistant/file.txt does not exist!" (or similar)
This is because Ant1.x delays evaluation of some constructs until they are referenced. Where as in Ant2 the idea was to unify all evaluation of "build model" to when execution occurs. So in Ant2, the <path/> data type would be evaluated imediately before any target was executed and thus would generate an exception regardless of target.
That seems like a very undesirable change. Referencing datatypes is primarily used to minimize boilerplate constructs and having a reference to a datatype mean something different than the same content expanded inline seems very undesirable. That would mean resorting to entity expansion to use the same boilerplate constructs in different contexts.
This becomes especially painful when you are dealing with things like filesets. You have to decide when the list of files is evaluated. Is it when declared, when it is first used or everytime it is referenced? In ANt1.x it is kinda haphazard (first time referenced unless it does not have any propertys to expand in which case it is declaration) and getting it to work consistently with Ant2 datatypes is a little painful (though possible).
Other build systems GNUMake (and CONS from what I hear) explicitly allow user to declare whether filesets are re-evaluated every reference or just once etc. I would love for Ant to get to the same level of clarity.
I would think the easiest way would be to control the timing of the fileset evaluation by its placement in targets, but allow the result set from a previous evaluation to be used. Maybe something like:
<project>
<target name="init">
<fileset dir="foo" includes="*.bar" saveAs="fooset"/>
</target> <target name="compileFoo1" depends="init">
<javac>
<fileset loadFrom="fooset"/>
</javac>
</target>
</project>Assuming there are no other XML dialects in the world. Having the Ant element namespace qualified would prevent an Ant project pretty printer from being misapplied to a freeway construction project or vice-versa. Also, mixing unqualified elements with namespace qualified elements (which I believe were considered for extension tasks and types) is just ugly.
This is just one of the peculiarities of the way ant as it has grown up and one peculiarity that we would like to fix in Ant2 (but is incompatible with Ant1.x). Other changes that are incompatible ways of evaluating propertys. ie In Ant2 it is mostly decided that ${x} should throw an exception if x is undefined but this behaviour is different (and incompatible) with ant1.x.
These are just two issues that imediately come to mind when executing ant1.x files in ant2. While the syntax of ant1.x can be easily translated into ant2 and the Task API can easily be adapted between the two versions. There are still real issues that need special handling.
Hence why I believe that there will be no simple transformation of ant1 build files to ant2 buildfiles. Or if there is the transformed buildfiles will have to have directives to ant runtime that indicate it should operate in certain ways. (ie One directive may indicate that unresolved proeprtys should not cause an exception to be thrown)
<!-- Ant 1 --> <project>
<!-- Ant 2 --> <project xmlns="http://jakarta.apache.org/ant/2.0";>
Or even more simply...
<project> <!-- ant1.x --> <project version="2.0"> <!-- ant2 -->
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
