Using non-standard Ant tasks - how to add jars to classpath?

Douglas Bullard wrote:

I've been playing with TeamCity, and have had a problem with all my build scripts. We use some non-standard Ant tasks (some from the Ant Contrib, some we've written ourselves). Normally, you just drop the jar required into Ant's lib directory.

But with TeamCity, there doesn't seem to be any way to do this (at least from the UI). There is a way to point to your own JDK (which we have in our project repositories), but not to your own Ant installation (which we also have in our repositories - deals with the issue of many projects not always being up to running on the same version of Ant).

Is there any way to address this? Either by telling the build which extra jars to use in the Ant's lib dir, or tell the agent to use a custom Ant dir they way you can tell it to use a custom JDK.

Currently, the preferred way to specify alternative ant home is to set system environment
variable ANT_HOME on the agent computer.

There is an alternative - in TeamCity/webapps/ROOT/update/plugins directory there is ant165.jar
file, which contains ant distribution, used by the TeamCity. You can package your ant with your
custom jars into such archive and replace ant165.jar in this directory. But you should keep the same
directory structure as in original ant165.jar. After the replacement all build agents will be
automatically upgraded and new version of ant will be used (no restart needed).

Hope this helps,
KIR

--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

The best way of dealing with this is to explicitly import the task into ant with a reference to the jar in question. It takes a bit more work up front, but means that any copy of ant, whether from the command line, an IDE or something like TeamCity, will work without manual intervention.

As an example, we use a task called vizant, and we have something like:

after which we can access the ]]> task. Since we have all the optional jars checked in, no matter where the build is done and with what instance of ant, we will pick up the optional jars without having to rely on the auto mechanism used by the command line ant.

--Tim

Yeah, I've started doing that, but it is a pain. Plus, we've got old projects that aren't using the same version of Ant as TeamCity, and that's the sort of thing that makes our project architects nervous (yes, we should upgrade - but then you're touching old, legacy code. It's political).

Thanks for the help.

I'll try specifying the ANT_HOME and seeing if that works...

The problem is that we have several versions of ANT (some old, legacy projects), and not every project has the same version of libraries. Also, our project architects like to have control over which version we use, so if the build tool uses a different version, we're not automatically dragged into using it (they're control freaks, what can I say).

Thanks for the help!

Doug

Yeah, I've started doing that, but it is a pain.
Plus, we've got old projects that aren't using the
same version of Ant as TeamCity, and that's the sort
of thing that makes our project architects nervous
(yes, we should upgrade - but then you're touching
old, legacy code. It's political).

Different versions of ant is the real issue here and I should have mentioned in my earlier post that my solution fails in this case. We're lucky enough that all our projects are on the same version and that it is always pretty current (almost all of our ant files are in common templates (some 5k lines worth) so the individual project ant files can be kept under 200 lines, with the added benefit that everyone is okay upgrading to a newer ant.

But if you are using different versions and have incompatible usage, you are kind of stuck. The explicit import is a huge win, though, even in this case. We have people using several different IDEs and though you can reference an external ant in most, we don't have to, which is nice.

--Tim

This should be satisfactory.


Thanks!