ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Corley \(AT/LMI\)" <david.cor...@ericsson.com>
Subject Specifying additonal classpath elements when calling the <ant> task
Date Thu, 01 Mar 2007 13:48:15 GMT
I'm wondering if anyone knows a way to specify additional jars for use
by an <ant> task within an ant buildfile.

My current setup involves 2 build files, builda.xml and buildb.xml.
Builda.xml runs an <ant> task to kick-off buildb.xml.  This a
multiproject setup. 
There are many users having their own custom builda.xml, but they all
call the same buildb.xml.

The problem is this:
In buildb.xml, I make use of Ant's <mail> task, which requires the
javamail and jaf jars from sun. From what I can tell, the only way to
get them on the classpath is to either:
A) add from the command line with -lib
B) drop them into the /ant/lib directory.

Neither of the above is entirely practical for our setup. We would have
to change every build script for the -lib option, and not every user
uses the same ant installation, so dropping the jars into the ant/lib
directory isn't entirely practical, as well as the fact we want to
separate 3rd party jars for version control purposes.

So basically, I'd like to run my buildb.xml and specify additional jars
to be added to it's classpath that are not in builda.xml.
(I know I can use inheritall/inheritref attributes in the <ant> task and
specify the jars in the builda classpath, but I specifically only want
the jars to be used by buildb)

An suggestions/ideas?

/Dave

This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete
the message without disclosing it. Thank you.
E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any
such corruption, interception, amendment, tampering or viruses or any
consequences thereof.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message