ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <>
Subject Re: Tool Integration Problems
Date Sat, 09 Dec 2000 16:21:52 GMT

James Cook wrote:
> I may be beginning to see why the antitdote team resorted to parsing the
> build scripts themselves, as opposed to simply using the Project-Target-Task
> objects that Ant produces.

Thanks for noticing :-) As you probably discovered, Antidote has a
sub-package called "acs" which is short for "Ant Construction Set" :-]
The idea is to provide a set of classes that allow for easy run-time
construction of build data definitions, including instrospection and
customizer support throught the JavaBeans API (see below).

> It appears that a Task does not have to conform to JavaBean standards,
> meaning that there is no way for a tool to ascertain what value an attribute
> was set to. For example, given a particular Task such as, there
> is a setDir(File) method, but no getDir() method. Therefore, a tool that
> wants to display the value of "dir" to a user for editing is out of luck.
> The only alternative is to parse the XML file manually to obtain the value
> of these attributes.

I know that there are a lot of people on this list that are strongly
against adding API methods to the Ant data model that aren't needed by
the core of Ant. I personally don't understand the emphatic resistence,
but I've decided just to live with it and move forward with the ACS. It
has definately slowed down Antidote development for me, but it does
afford me the ability to enforce certain design patterns, such as the
JavaBeans one. In the ACS, the data model classes do conform to the
property access specification, and also implement the change event
semantics, all with very little additional coding (I have a base class
where the common event and property handling is implemented). Where I
have spent, and will end up spending, additional coding outside the data
model that is necessary for only the GUI (right now) is in the
implementation of full featured BeanInfo classes. Here I'm defining the
set of property accessors that I want truly exposed via the GUI (a
subset of the possible), and providing user friendly descriptions of
each property. I also define customizers for each JavaBean, although
they all right now default to my DynamicCustomizer that is basically a
property sheet.

If I /were/ king 8^], I would require that the tasks (and Project and
Target for that matter) conform to the JavaBeans specification,
supporting proper get/set semantics where appropriate, and encourage
that they use change event support provided by some abstract base class.
This is hardly "extra" work, and it certainly has no performance impact.
I would *not* require the BeanInfo support, as that *is* a lot of extra
work you don't want task developers to care about. If they want
sophisticated support in Antidote (rather than simple instrospection
based editing) then they would need to implement a BeanInfo class, and
maybe a Customizer for it, but that is a different issue, and can be
tackled by a different developer.

> tool integration. Has this started? (I think it is perhaps overkill.) Simply
> forcing Task authors to provide getters may be good enough. This can be
> validated at parse time (in IntrospectionHelper) for enforcement.

You know where I stand on this (although I don't think run-time
enforcement is necessary, just peer review), and I feel that I've heard
a lot from dissenters on this issue. 

Are there any other supporters out there, or are we truly in the
minority on this? Does it have to do with unfamiliarity with the
JavaBeans spec, and a belief that it is only for GUI builder support, or
is that basic stuff for everyone?

> I feel if each tool is responsible for parsing a build file then we are in
> for a world of hurt regarding compatibility.

That is where we are now. I haven't had the time to look at Anteater
yet, or myrmidon, so I don't know where the revolution proposals stand
on this. I'm hoping that the core Ant developers keep an open and
objective mindset and consider the long term possibilities of the tool.


View raw message