Re: ComponentHelper replacement

[Steve Loughran <st...@apache.org>]

Stephen McConnell (DPML) wrote:
>  
> 
> 
>>-----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.

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

RE: ComponentHelper replacement

["Stephen McConnell (DPML)" <mc...@apache.org>]

 

> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org] 

<snip/>

Apologies for the delay in responding (have been 
swamped with moving house and the cup).

> > 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

I'm thinking along the lines of moving the ant codebase structure to 
something that reflects a project codebase per jar file where each 
project (a.k.a. ant-sub-project) would have its own build file, 
clearly identified dependencies, testcases, and resulting artifacts.

Could this be a feasible post-1.7 objective?

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