[EMAIL PROTECTED] wrote:
Nicola Ken Barozzi <[EMAIL PROTECTED]> 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 [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]>
