[EMAIL PROTECTED] wrote:
[snip]Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote on 07/08/2002 05:44:47 PM:
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
