ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Fuller <>
Subject Re: AW: 1.7 release timetable & features.
Date Fri, 25 Feb 2005 12:35:03 GMT
Steve Loughran wrote:

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

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

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

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

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

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:
For additional commands, e-mail:

View raw message