Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <005001c3f1ee$09f35bc0$1a630d04@PAULHOME>
From: "Paul F. Williams" <paul128@verizon.net>
To: <dev@ant.apache.org>
Subject: notes on embedding ANT
Date: Thu, 12 Feb 2004 22:58:36 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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
properties.

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
engine.

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
Objects.

4) It would be nice if org.apache.tools.ant.helper.ProjectHelper2 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
design.

One potential pitfall I see is ProjectHelper2 line 199:

        inputSource.setSystemId(uri);

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org