Hi Conor and fellow Anters,
Beside a couple comments below, I'd like to discuss the addition of another
feature to Ant for 1.6 wish I think would be very valuable, and make Ant
much more user friendly (in my setup at least).
We have quite a few projects here built using Ant, and very similar looking
builds (I look forward to <import> which hopefully allows target overriding
to achieve some kind of customizable templating system), all using a version
of Ant under CM enhanced with a few "AntLibs" like Ant-Contrib, CppTasks,
and our custom tasks.
The practice here is for people to work in 1 or 2 or many projects, and do
CVS updates at the top level of the projects, thus picking up the project's
build.xml.
Problems arise when I update a project's build.xml, making use of either new
tasks/types or updated ones with additional attributes, because developers
seldom update the CVS module (buildtools) that contains Ant, which results
in confusing errors for my users (numerous and sometimes not very Ant
aware).
I can either send an email out to the people working on the project(s),
telling them to update buildtools if they update this or that project, but
it's far from efficient with the flood of emails everybody gets (one often
do not want to update when working on something, and later forget the
message, if it was noticed at all).
I tried to solve that problem by having a custom task in the build file
itself that lists the minimum version of the custom tasks required by the
build file and project at hand like so:
<buildtools action="check-version" minimumVersion="30403.16" />
This will fail the build whenever the local version of buildtools is older
than what's required, with an appropriate message telling that buildtools
needs to be updated. So all developers were told once to update buildtools
by email (a lot of projects used their own Ant version, either checked in to
the project itself, or an official distrib to be downloaded and installed
manually, but all of them now use the same Ant), and then it's the build
file itself that informs users when updating is necessary.
It does work when the build uses new tasks! In this case, the unknown
task/type is wrapped in an UnknownElement to be hopefully resolved at run
time (rather than parse time), but my task above runs before that and fails
the build with a clear and explicit message (update buildtools!).
However, when an existing (custom) task/type is modified, Ant fails at parse
time saying this task or type doesn't support this attribute or nested
element (which is of course available in the latest version of buildtools),
never giving the chance to my <buildtools> task to run, and instead failing
with the usual confusing Ant error message...
My solution is probably naïve, and I'm not advocating its adoption, but I
*really really* would like this particular (little) problem solved. It would
make Ant much more user friendly, and I hope it could be in Ant 1.6.
Thanks, --DD
> -----Original Message-----
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Subject: Re: Ant 1.6 todo thoughts
> I will be working on the lcp.bat replacement next. This will address the
> command line too long, environment space issues, etc.
Are you going to work in some sort scripting language like Perl or Python,
or more a Java solution from inside Ant playing with ClassLoaders?
> How do we want to approach bringing in try-catch? I'm +1 on the idea but
> unsure of the ant-contrib situation in terms of granting that code to
> Apache. Thoughts?
I've used try/catch only once temporarily in Ant, so I'm +1, but one task
that I think would be a tremendous addition to Ant is <outofdate>. This is
light year ahead of playing with target dependencies and <uptodate>!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
