ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: IDE's integration with Ant any clues
Date Tue, 14 Apr 2009 03:19:35 GMT
Raja Nagendra Kumar wrote:
> Some think in the scope of Ant Plugin Development Support API focused around
> IDE integration, so that these api could much richer and closure to ease IDE
> integration support.

Maybe. I don't see much value in it from my experience. What the IDE needs to know for basic
editing support and source navigation, it can find out by parsing the XML. 
Richer information is only reliably available by actually running the script anyway - Ant
is essentially an awkward scripting language, so you can't reliably predict what 
it's going to do until you try it (due to the Halting Problem). As a quick example, <import>
can be given a filename to import for extra targets, but this filename can 
contain variable substitutions, and you might have run arbitrary computations by this point.

(NetBeans tries to simulate "computed imports" up to a certain level of complexity, and punts
on anything beyond that - fortunately rare.)

> I did not understand "calling into Ant code merely for browsing
> would pose security and reliability issues"

When the IDE needs to know some information about an Ant script - say, a list of targets -
there are two kinds of things it could do:

1. Parse the XML directly. This is what NetBeans does.

2. Call a method in ant.jar (embedded somehow, or forked as a separate process) asking it
to parse the script and return that information.

In principle #2 would be fine, and for some other cases it is. In the case of finding a list
of targets, however, asking Ant to supply this information is unsafe. Just 
running 'ant -f $script -p' causes top-level tasks (those not inside <target>) to be
run, which is necessary for <import> to work correctly in some scripts (as noted 
above). This is a little surprising for command-line Ant. But it would be unacceptable if
the IDE were silently running this command whenever you, say, selected an Ant 
script in the IDE's file explorer when a structure view was open! The Ant script might have
been written by some malicious person:

<project default="hello">
   <delete dir="${user.home}"/>
   <target name="hello" description="Look at me, I am harmless!"/>

and just clicking on it would cause your home dir to be deleted. (Whereas if the user explicitly
invokes some kind of Build action, then they are signaling that they 
trust the script.)

So the only way an Ant API to provide information such as a target list would be useful for
an embedded environment like in an IDE would be if it

1. Guaranteed that user-defined tasks are never run as a result of calling the API - only
code in Ant itself.

2. Guaranteed that only Ant standard tasks which are known to be "read-only" are run. For
example, <property file="..."/> is OK, <echo file="..."/> is not.

3. Otherwise protected against infinite loops and other kinds of errors that could be introduced
accidentally or maliciously in user scripts.

4. Were about as fast in the typical case as a manual parse of the XML script.

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

View raw message