ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Ant 2 et al.
Date Mon, 08 Jul 2002 07:44:47 GMT wrote:
> Nicola Ken Barozzi <> wrote on 07/08/2002 04:03:41 PM:

>>>Possibly. And it may also take a lot longer to get there than if we 
>>> adopt 
>>>one of the proposals now, and freeze the Ant 1.x code.
>>>The proposals now are not ready IMHO for a code switch.
> Really? I'd be interested in what you'd consider ready, given your 
> experience with Ant 1.x.

 From the CVS commits.
Too many and too substantial to think that what is in there is stable.

>>I know that it will take more time, but it could make a better product.
>>I've seen many projects change codebase and really suffer it, so if it's 
>>to be done, it will have to give substantial benefits.
> Which none of the codebases do from a user perspective? Or am I reading 
> you wrong on this one?

I think they don't give *substantial* benefits to the majority of the 
Ant users. Maybe I'm wrong.
Take for example Cocoon1->Cocoon2
It was hard to switch, but with the DOM usage and no central sitemap we 
had really hit a ceiling (ie could not improve memory usage and 
administration of webapps), which I don't see with Ant1.

>>I don't see (maybe I'm wrong) that these changes are that important to 
>>justify the codebase switch.
>>Excuse me if I repeat myself, but what are the features that Ant doesn't 
>>give you that you need?
> See the Ant 2 requirements list....
> But on my personal list:
> - Better expression usage. See Jexl. Access to java objects rather than 
> just flat string properties.

Better expression usage can be done. (IIUC there isn't really in Ant1)

But why access to java objects?
I see this as unnecessary for what I've done till now, and regard it as 
unneeded flexibility.

> - More flexible include/import/antlib 

In the works.
Antlib just needs hopping in 1.6 codebase after the release.
Import is there as a patch.

> - Default processing for various tasks, e.g. run an ant task without a 
> build file, if all it wants is a simple property that can be made 
> available from the command line.

Sorry, I don't understand, can you explain again?

>>Maybe we could work to put them in Ant1.
> Maybe, but the project/task/target/datatype architecture is a hindrance... 

Well, it's easy for users to understand.

> For example, take datatypes. They have no well defined lifecycle as tasks 
> do, and would really be better off not existing. Straight java code/beans 
> would suffice for most uses. 

Why lifecycle? What lifecycle should they have?

Do you propose that each task has his own beans to use?
How could I then use the same datatype definition in different task, do 
I have to learn zillions of datatypes?

>'Project' really isn't a project, it's a 
> 'Build'. Myrmidon tries to integrate more 'project information' into the 
> descriptor (similar to Gumps, right Peter?), rather than being Build 
> focussed....

Still don't know if it's good, I tend to think that these infos 
constrain unnecessarily Ant scope and are better off in systems that 
build on Ant... not sure though.

>There are a ton of API issues I have with Ant, e.g. property 
> contexts being a single flat list, and not 'shareable' between called 
> builds.....

would <import> reduce the problem?

> All of my issues are solveable in Ant 1, but from what I've seen it'd be 
> easier to solve with either Mutant or Myrmidon.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message