ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell \(DPML\)" <mcconn...@apache.org>
Subject RE: ComponentHelper replacement
Date Sun, 28 May 2006 17:36:42 GMT
 

> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org] 
> 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:mcconnell@dpml.net
http://www.dpml.net
 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message