ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul F. Williams" <>
Subject notes on embedding ANT
Date Fri, 13 Feb 2004 04:58:36 GMT
I'm an ANT newbie.  Please forgive any newbie offenses.

I want to use ANT's task engine in my own app.  I don't want to invoke it
from a command line.  I don't want to run individual tasks myself.  I want
to use the ANT engine internally to process an XML script.  Maybe there is
an established way to use ANT this way, but I found none.

This script is in the META-INF directory of a JAR file.  I don't want to
extract the file to a temporary file and feed it to ANT.  Instead, I would
like to convert the script's ZipEntry to an InputStream and pass the stream
to ANT.

My current solution installs a project helper remarkably like the current
ProjectHelper2 class.  The main difference is that my parse() method is more
friendly to InputStreams.

My app's main method points ANT to my helper class via the system

I have an ANT engine wrapper much like Main.runBuild() that duplicates the
logic to run ANT.  It uses an InputStream instead of a File.

Everything works.  I pull the script as an InputStream and pass it to the
wrapper.  The wrapper passes the stream to the helper.  The helper parses
and runs the script.  (My next step is to provide my own specialized tasks
that I want ANT to resolve without a <taskdef>.)

Here are some obstacles I had to overcome:

1) I had to duplicate much of the functionality of the Main.runBuild method.
It would be nice if Main.runBuild() were refactored into a generic way to
start the ANT engine.  Doing so would make it easier for others to embed the

2) Main assumes a File (which is OK), but it would be nice if the code that
starts the engine would take an InputStream.

3) ProjectHelper.configureProject takes a File.  The actual
ProjectHelper.parse method takes an Object.  It would be nice if both used

4) It would be nice if were
friendly to InputStreams.  In fact, all the SAX parser needs is an
InputStream (converted into an InputSource).  The parser would not need to
close the stream; higher level methods would determine when to do so.  The
existing Main class would send a FileInputStream.  Other apps might send
their own InputStreams.  In short, streams seems like a more flexible

One potential pitfall I see is ProjectHelper2 line 199:


If the helper gets an InputStream, it will not have a URI.  I did not set
the URI, and it worked ok for me, but I don't know all the ramifications.

Do these suggestions sound reasonable?  If so, how might this pitiful wretch
of a newbie contribute?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message