Stephen McConnell (DPML) wrote:
-----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.
I'm sorry, I have to work with XSD as my day job. It's evil and wrong.
It's one of the primary causes of grief in the whole O/X mapping area,
and it is very hard to work with.
Only people with a formal CS background and experience in those
mathematical language models can begin to understand all of it, and even
then it doesnt make sense to most of them.
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.
that sounds like one of my comments. Programmatic use of ant is always
secondary. Do we want to change that? If so, how?
-split out libraries for execution, java exec, other misc things
-complete programmatic use of ant without problems
In particular:
(a) default bootstrapping scenario presumes user intervention
you mean the double step of bootstrap/build?
(b) default build file exemplifies a bad-practices (mixing core with
external dependent builds) resulting in a complex 67kB XML file
yes, its got a bit big.
(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
we could write (and maintain) another .bat/.sh for this.
(b) build metrics created as a part of the build process
reasonable.
(c) publication content (apis, junit reports, checkstyle reports, etc.)
generated as a part of formal distribution content
possible. Would be nice up on the web site as a proof of 'compliance'.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
