NB now includes Ant 1.5.1. Everyone is using it.
The NB build supports it, yet assumes 1.4.1 as the
baseline. Why?!
- 1.5.x supports debuglevel attr on <javac> which
we need
- XML tasks can use catalogs, enabling us to
discard org.netbeans.nbbuild.XMLValidate, use
<style> offline, etc.
- many other bugfixes and improvements which we
cannot take advantage of currently

Filed the SignJar problem separately as that should be fixed for 3.5 -
i.e. in 3.5 it should be *possible* to use Ant 1.5.2 (with 1.4.1 the
supported version) whereas in the trunk it should be *required*.

It seems <style> is badly broken on 1.4.1 also for some cases where
the stylesheet uses entity includes which use relative paths going to
near the root of the Unix filesystem. Apparently fixed in 1.5.2;
possibly Ant bug #6259, possibly something else.

In the future is it possible to keep the build ant version
and the ant version that we ship with the product
consistent?
With the way we are doing it now (the build scripts lag
the product), it seems like we could get into a situation
where ant scripts that work inside the IDE would not work
outside the IDE and visa versa.

I agree that consistency between the bundled Ant and that used for
builds would be desirable. But first priority for each is making them
be current. IMHO NB dev sources should support any new stable Ant
releases within a week or so of its release, a month at the outside.
This could probably be said of other libraries too of course. Anyway
that is all a broader topic suitable for nbdev but somewhat out of
scope here.

Michael,
such inconsistencies are not only in our hands. Apache Ant is well
known for introducing huge incompatibilities between releases ;-( and
also turnbacks in further releases.
I agree with Jesse, that keeping consistency is desirable, but not
feasible with current Apache Ant's developers approach to backward
compatibility.

To clarify: the Ant project definitely pays attention to compatibility
of build scripts, and generally also to custom tasks. However NB has
some tasks which either (1) do bizarre things with the Ant core such
as dynamically add targets to a build, or (2) directly refer to the
implementation classes of existing tasks.
Such dumb tricks are not generally supported, so we sometimes need to
do a bit of work to upgrade the build system to a new Ant release. I
would not call them "huge incompatibilities"; most commonly a
parameter changes from String to File or something like that. An
hour's work for a programmer maybe. (In this case, the 1.5.3 support
work is already done I think - we only need to *require* the new
version rather than merely *permit* it.)

I've forgot to mention, that the referenced build 200305150700 is just
test build, even it was run in full production environment, just with
different Ant release. The report was not a promise of any kind. I'm
sorry, if there was any misunderstandings.