ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: Ant 2 et al.
Date Mon, 08 Jul 2002 07:36:05 GMT
Nicola Ken Barozzi <nicolaken@apache.org> wrote on 07/08/2002 04:03:41 PM:

> dion@multitask.com.au wrote:
[snip]
> > Which isn't really the point though is it? The idea of proposals is 
for an 
> > eventual vote, not as a sandbox for development.
> 
> Well, maybe, but I find what is happening here quite interesting as per 
> the dynamics.
> I never thought that the proposals would be put in the codebase piece by 

> piece, quite interesting outcome IMHO.
And yet that is what is happening. People are reimplementing functionality 
from the proposals/Ant 2 requirements as Ant 1 code.

> Anyway probably we will switch codebase, but the transition of Ant1 will 

> have it more aligned in features to Ant2, making the eventual switch 
> less painful for users.
I'm not sure a codebase switch will take place. I've seen no evidence of 
it so far, I've effectively seen three separate projects running side by 
side.

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

> 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 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.
- More flexible include/import/antlib 
- 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.

> Maybe we could work to put them in Ant1.
Maybe, but the project/task/target/datatype architecture is a hindrance... 
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. '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....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.....

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.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message