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!"/>
</project>
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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
