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 08:51:34 GMT
Nicola Ken Barozzi <nicolaken@apache.org> wrote on 07/08/2002 05:44:47 PM:

[snip]

>  From the CVS commits.
> Too many and too substantial to think that what is in there is stable.
I haven't seen many from Mutant lately. Conor, what sort of state is it 
in?

[snip]
> Better expression usage can be done. (IIUC there isn't really in Ant1)
Anything can be done...it just takes time and effort.

> But why access to java objects?
> I see this as unnecessary for what I've done till now, and regard it as 
> unneeded flexibility.
We already have java objects available as datatypes, e.g. xmlcatalog, path 
etc. This is 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.
Yep, on top of the existing classloader issues.... I'm not saying it can't 
be done with Ant 1. It can.

> > Maybe, but the project/task/target/datatype architecture is a 
hindrance... 
> 
> Well, it's easy for users to understand.

I've never seen anyone who implicitly understood why some tasks were 
allowed outside targets. Or what was a datatype vs a task, nor where if="" 
was allowed.

> > 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?
No, do you :)

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

> 
> >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?
Nope. What happens when I import a build file that redefines a task so 
that the classname is different to the 'master' build file that imported 
it?

Also, the thrill of optional.jar and friends today leaves me cold. Ant 
could do with some serious redefinition of the task categories.
--
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