Steve Loughran wrote:
[EMAIL PROTECTED] wrote:
- 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.
+1 will take a look at it.
yes exactly, with a bit of sugar to give hints as to which project name to execute....remember we think in files today because they are physically (well not really) demarcated...when working with xml databases, or massively compound xml documents its namespaces that demarcate.
- 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).
understand, will take a look
perhaps a Junit2 or maybe even a generic <test/> (though I see we have a deprecated tag) that can bundle up pre/post tasks to tests, such as loading multiple datasets, etc...would be interested in suggestions, but am scared of major changes to what is a pretty essential piece of code.
- junit task IMHO needs revamping, coordination of test processes across dbunit, xmlunit, and junit would assist...more thoughts on this later
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.
neat...
- 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.
will take a look
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.hmmmm, makes complete sense...though there will always be a need to put other bits elsewhere...
- 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?
no, I have already gone through the input masking fun....its more about locking down...or giving the opportunity to lock down; e.g. secure class loading, working with digital certs, etc...
Jim Fuller
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
