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 Mkdir.java, 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. sim
