ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Ant Java API and NetBeans integration - ruminations
Date Thu, 25 Jan 2001 13:37:19 GMT
So I've been lurking on this list for a while now (lack of time) and
since I am the current maintainer of the Ant <-> NetBeans integration
module and there have been some threads relevant to that, here are some

1. There was a thread about how Ant should expose its buildfile
structure to GUIs, and proposals for including DOM-like APIs in various
Ant classes etc. My viewpoint is closest to that of Jose Alberto
Fernandez ("Re: Did somebody say Shut up and Write? :)" 12/21/00), esp.
(3) "XML Language": that the user-visible XML representation should be
the principle way Ant interacts with tools too. I guess there is no harm
done if there are others, but the NetBeans integration at least does not
need them. It lets you write Ant-compliant XML, and lets ProjectHelper
etc. interpret the result. The tool can use DOM or whatever it likes to
generate this (CPU overhead relevant to execution is negligible).
Development-time modification of scripts can be done perfectly well in
plain XML; so long as the basic syntax of the buildfile is not made
excessively complex (and I think everyone wants this anyway) then it is
not much burden for the tool to create and validate it. The current
NetBeans module actually uses task/type introspection to provide a
constrained UI for the XML tree. If XML editing support in NetBeans is
made more powerful (and I hope it will be), then the module can use
NetBeans-specific functionality to improve its UI; any* support would be superfluous. If you want to
modify the build structure in the middle of execution then I guess
something more than the XML textual representation is required, but I am
not sure why you would want to do this.

2. For reference, the NetBeans module currently uses these APIs to work:
(a) Project constructor and init() method; (b)
Project.setDefaultClassLoader (if my patch is accepted, else some other
existing stuff as workarounds); (c) IntrospectionHelper (for the UI:
e.g. right-click on a <zip> node and be presented with valid subelements
to add); (d) Project.setUserProperty; (e) BuildLogger interface &
Project.addBuildListener; (f) ProjectHelper.configureProject; (g)
Project.executeTargets; (h) BuildException and Location and related
methods for displaying errors; (i) EnumeratedAttribute (for GUI:
pulldown lists); (j) Reference (for GUI); (k) Project.MSG_* constants;
(l) IntrospectionHelper, Project.getTaskDefinitions,
resource (for GUI); (m) Task (just the implementor part of the API).
Everything else is handled in XML without directly accessing Ant APIs.

3. Some (IMHO) messy things in the API that could be improved (in 2.0

a. ProjectHelper.configureProject: fine, but a variant accepting an
InputStream and a File "parent directory" instead of a File buildfile
would be helpful for embedding into tools.

b. Project.executeTargets: this call runs them as if supplied on the
command line, i.e. independently with no thought given to shared
dependencies. That is fine behavior, but a variant which did eliminate
duplicate dependencies would also be helpful. The required stuff is
private in Project, the only workaround is to make a new dummy target
("tmp-84673") depending on your list and execute that.

c. Project.fireBuildStarted and .fireBuildFinished are protected--why?
Main calls them as package-private, probably they should be public (or
Main should subclass and call them as protected). A different front end
cannot call them currently (the NetBeans module tells the logger
directly as a workaround).

d. Location is missing getter methods. toString() is not the best
interface to it.

e. BuildLogger should use PrintWriter's (or just Writer's), not

f. BuildLogger does not even seem that useful--it is an interface, yet
the API-ish stuff happens in BuildListener, and its methods are
implementation details that would be better set in a constructor or
dedicated method of some implementing class.

4. Thank you for making <echo> log instead of System.out.println, this
was welcome. (Actually the NetBeans module can trap raw prints but
getting a messageLogged is much nicer.) For the future, anyone
interested in making sure Ant stays embeddable in GUIs should think
carefully about doing these things: (a) System.exit (duh--actually
NetBeans will trap it if it happens, God forbid); (b) setting a security
manager (VM-global effect); (c) using ClassLoader methods referring to
bootstrap loaded (see my patch); (d) System.setOut etc.--actually
ExecuteJava uses these now and it works inside NetBeans, but is a
possible race condition with the enclosing IDE; better might be an
overridable "output trapping factory", default using System.set***, a
GUI could swap in its own technique (checking thread groups or something
to tell who is doing the logging).

Well that's plenty for now. Cheers to anyone who read this far down,

Jesse Glick   <>
NetBeans, Open APIs  <>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

View raw message