ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 19:16:53 GMT wrote:
> On 15 Jul 2002, Stefan Bodewig wrote:
>>>1. SAX2 support.
>>>While it is possible to use it as plugin, I would like to propose
>>>deprecating ( but not removing :-) the SAX1 helper and use SAX2.
>>As long as it remains reasonably backwards compatible, fine.
>>Otherwise we'd have to make the SAX1 helper the default (this silly
>>example of taskdef `name="test:task"ยด).
> I think we should first agree that <test:task> is at least against the 
> recommendations of the XML spec in the last 2-3 years.

Could you please explain the problem?
I don't get it :-|

> The big question is if we'll make the default be SAX1 - in order to
> support broken XML, or we'll make it just a non-default option.
>>>2. Classloader improvements.
>>Let's discuss this in detail - how it affects the exisiting user tasks
>>and how we can improve current Ant's situation without breaking them.
>>It seemed Peter and you are already agreeing on something that might
> IMHO the biggest problem at this moment is the fact that optional.jar
> is loaded in the system class loader. If we fix that, we can easily
> get junit and all the optional tasks to work without files in ant/lib.

Probably I'm missing something very very obvious here, but I'm usinh 
junit in Centipede without having anything of it in ant/lib.

I just removed the relevant classes from optional, removed the 
declaration for the task, and I'm loading it from another dir with a 
taskdef... :-?

> There are 2 solutions for that - one is to use a tomcat-like loader
> hierarchy. The other is to do a small hack ( I already checked some
> code in PH2 ) - create an AntClassLoader in non-delegating mode and
> load all the optional tasks through this loader. 
> The effect of this is that each optional task will be associated 
> ( getClass().getClassLoader() ) with the AntClassLoader we created. 
> And later on it is possible to add more jars to this class loader
> ( for example using a task or using a special Path ) - thus 
> making possible to use an arbitrary junit.jar.
> In any case, tasks that construct class loaders without specifying the
> parent will not work with this model - you'll have to put the 
> classes they need in CLASSPATH, as before. 
> Obviously, ant 'core' will have to remain in the main classloader. 
> It is reasonably easy to do the XML processing in a separate loader,
> so the parser used by ant can be hidden from user tasks ( if that's
> desired - to allow tasks to use a different parser, like a webapp can
> do ).
> Taskdefs already support using separate loaders, and I don't think
> changes are needed. 
> There is one extra issue - tomcat4 classloader supports the 
> manifest-declared dependencies. Using it would possibly simplify
> a lot - but it is JDK1.2 dependent, and most tasks/libs don't
> declare the dependencies very well.
>>>3. Dynamic properties - i.e. not stored in the Project's Hashtable
>>>but in a different and configurable source
>>I don't think I've understood your rationale when you've explained it
>>to Nicola Ken.  Reading properties from JDK 1.4 prefs or whatever only
>>takes a task - what would be the benefit of storing them in a
>>different way?
> There are few things here. First, I would like to make the properties
> repository 'pluggable'. If ant is embeded in an application, it should
> be able to 'see' properties under the control of that application.

Need for this?
Ant used as a generic scripting system? ;-)

> It is possible to have the app save all the properties in the 
> project hashtable, but that's not the best solution IMHO.

What's the use-case?

> Second, if you look at XmlProperty for example - it works by loading
> the xml and creating properties for each element. A solution for JDK1.4
> prefs would be to record all prefs ( in a subtree ) in the props
> hashtable. With the 'dynamic properties' patch - you could use lazy
> evaluation. You can keep for example the XML DOM as a reference
> and do XPath selection when a particular element is needed. 

Yup it could speed up the build.

> And of course, the whole ${property} mechanism will be more flexible
> and powerfull. We already allow some scripting, and this can be extended
> to ${} as well. It is in a way similar with the EL in JSP or velocity.

The biggest enhancement I see is the possibility of getting values for 
properties that are defined as xpaths for example.

A cool system we could use for this is

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message