Nicola Ken Barozzi 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 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