> -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Friday, 26 May 2006 10:59 PM > To: Ant Developers List > Subject: Re: ComponentHelper replacement > > Wolfgang Häfelinger wrote: > >>>My preference is to improve Ant's API. > > > > > > I would like to see Ant evolving in such a way allowing me to > > implement a framework like Maven on top of it.
I agree. IMO there are two views that could be addressed here: (a) build.xml integrity (b) the Ant implementation quality The first item (a) concerning build integrity is related to the integrity of the XML file parsed by Ant. I would like to see the build file evolve towards an XML schema compliant source which would suggest that there is a generic Ant schema with support for extended data types and task definition schemas. Validation of custom data and tasks at the XML Schema level would be a major improvement over the current status-quo through simple elimination of XML structural issues combined with pre-execution validation for custom tasks. Introduction of XML schema has build and runtime implications that would require evaluation of JDK version and XML API support. A worst-case scenario would be schema-enabled versus schema-unsupported distributions. A more immediate concern is validation of the Ant implementation - in particular, tests cases against the Ant distribution. An earlier thread raised by Subir Bhaumik on the subject of "Using Ant Programmatically" and the appearance of an NPE is an example of the type of problem that should not occur or at least should be easily replication within a junit or integration test. Looking into the subject of that thread its relatively easy to see that the scope of existing tests related to Taskdef are limited: public TaskdefsTest(String name) { super(name); } My immediate thoughts here are related to the process of Ant improvement. Subir's post as a minimum should be treated as a challenge - i.e. replication of the NPE in a testcase. Instead Subir was told to look at the source and figure this out for himself (which IMO is not equal to satisfactory process closure). I think that part of the problem here is that Ant is bootstrapping itself from nothing and as a consequence we have an overly complex build file that does not generate the information needed for rapid problem identification/resolution by the non-committer community. In particular: (a) default bootstrapping scenario presumes user intervention (b) default build file exemplifies a bad-practices (mixing core with external dependent builds) resulting in a complex 67kB XML file (c) no build metric (test case reports, etc.) for published distributions All of the above could be improved with some refactoring of: (a) the project structure (b) the build strategy (c) published metrics The build structure could be improved with the separation of core from extension projects (with the assumption that each extension project addresses the specific extension concern). In effect, each project could represent the build solution for each of the package Ant jar file included in the formal Ant distribution. With rationalization of build structure the build strategy could be significantly improved by using a released (bundled binary?) version of Ant as the build system - enabling a much more rigorous evaluation of the result (junit reports, coverage, etc.) with respect to the Ant core and specific extensions (without the user intervention prerequisite). Given the above - it could be reasonable to assume: (a) a complete Ant build without user intervention (b) build metrics created as a part of the build process (c) publication content (apis, junit reports, checkstyle reports, etc.) generated as a part of formal distribution content Cheers, Steve. -------------------------- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]