Having spent the past several hours trying to solve what ought to have
not even been a problem to begin with, I've noticed something about
Ant.
It appears that Ant as it is delivered comes with a bunch of optional
tasks that it knows about inherently, such as the Scp task.
It also appears that while Ant ships knowing what these tasks are, it
does not ship with jars they depend upon, such as jsch. The
documentation tells you to go out and get these jars on your own, and
put them in your Ant lib folder.
Here's the part I don't like. When Ant starts, it appears to try to
load optional tasks like Scp. When such tasks fail to load the first
time, due to the dependencies not being there, it is then impossible
to recreate a task with the same classname later using a taskdef
element, even if you include your own path containing all the jars it
needs.
Let me explain why this is a big issue. I work in a team. X number of
developers on my team share the same build script, on far-flung
machines.
I want to add Scp to the build script. I cannot simply manually put
the jsch jar in my own Ant lib folder. It won't work when anyone else
on my team tries it.
Instead, I need to check the jsch jar into my project along with the
ant script. Then, every developer on my team who gets the new script
will also get the jar to go with it. So far this seems fine.
The problem is that when the developer runs Ant, I still cannot
instantiate the Scp task because the jsch jar is not in the classpath
when ant starts. And, for some bizzare reason, I cannot even define a
new scp taks using a taskdef element with a classpath (the way you'd
do it if you were deploying your own task). Why this fails I don't
know. My guess is that Ant somehow keeps track by class name that the
task failed to load when Ant started, and refuses to try to load it
again.
I tried many ways to solve this problem, including copying the jsch
jar into Ant's lib folder. Nothing works because before I can do
anything Ant has already decided that Scp is an unloadable task.
This is terrible behavior. Ant should either not come with "optional"
tasks predefined that won't load, or it should at least offer the
chance to reload them with a specific classpath later.
Can anyone think of any way around this problem?
Roedy Green - 13 Jul 2007 16:49 GMT
>Can anyone think of any way around this problem?
The practical solution is to collect all the ant jars and get them
installed on all developer machines. Ant people likely did not do
this because at the time most people just had dial up and small disks.
Now the inconvenience is not worth the saving.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com