ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Ant 2 et al.
Date Mon, 08 Jul 2002 09:00:36 GMT

dion@multitask.com.au wrote:
> Nicola Ken Barozzi <nicolaken@apache.org> wrote on 07/08/2002 05:44:47 PM:
> 
[snip]
>
>>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?

Maybe.

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

These are minor issues.
We're talking bout the project/task/target/datatype architecture, not of 
how it's implemented.

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

;-)

Then I don't get your point.

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

This is the point, IMO you should never give the user ability of 
redefining stuff. I'm working now to make the import tag handle this by 
renaming names on the fly if requested.
If you have build files that are so diverse in how they define things 
you just use <ant>.
Even in Java you can have name collisions if you don't follow the 
package naming conventions.

> Also, the thrill of optional.jar and friends today leaves me cold. Ant 
> could do with some serious redefinition of the task categories.

?

Antlib will make it more granular, what's the problem?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message