- manual needs some pretty generous scrubbing and reorganisation (note: not a fan of any of task styles used...ex. WhichResource) and generally a fresher look and feel.
WhichResource is one of the xdoclet generated docs. New velocity/XSLT can improve that.
- would like to embed namespaced xml (dublin core, etc...) that are ignored by Ant if Ant doesnt know about it e.g. generally be able to embed ant scripts into compound xml documents and process normally.
ant is NS aware now. Do you want the ability to ignore stuff in other namespaces that it doesnt recognise?
- <libraries> stuff is very important to me; having the ability to define reusable classpaths with <libraries/> would be very useful (not just embedded in java task)
This is in CVS today, but I want to add security . 1. ability to declare that all libraries must be signed by someone you trust 2. ability to check external checksum of a JAR
we cannot sign all jars in the maven repository, because of the side effects on the JRE (semi-seals the packages).
- junit task IMHO needs revamping, coordination of test processes across dbunit, xmlunit, and junit would assist...more thoughts on this later
would be interested in suggestions, but am scared of major changes to what is a pretty essential piece of code.
I am trying to get distributed junit working @ work; reporting is on the todo list there. It isnt part of <junit> though, just another test runner that you deploy onto systems on the net.
- Ant should have some basic built in autodoc tool for scripts...once again I am working on something...and others have attempted.
there is an old one in proposal/xdoc, that could be used as a starting point.
Certainly xdoclet makes sense as the foundation, but we need more control and to move to fully automated docs (a good things) we'd need to move *all* existing docs into the javadocs of the source. That will take effort. Worthwhile effort, especially for IDEs that could have an XML representation of tasks/types and elements/attributes for better display.
- secure processing is a problem with ant, as it is with any build tool....been looking at ways of enhancing standard task definition to be more 'security' aware....internal/external properties,passwords, in memory management, secure deletion of sensitive artifacts etc...a bit of hardening would go a long ways in considering Ant's usage in different development environs
We try not to intro more security holes. Are you thinking mainly about password management?
-steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
