ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: AW: 1.7 release timetable & features.
Date Thu, 24 Feb 2005 15:55:03 GMT 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.

> - 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 

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

We try not to intro more security holes. Are you thinking mainly about 
password management?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message