ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 17:41:13 GMT
On 15 Jul 2002, Stefan Bodewig wrote:

> > 1. SAX2 support.
> +1
> > 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.
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
> work.

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.

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.
It is possible to have the app save all the properties in the 
project hashtable, but that's not the best solution IMHO.

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. 

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.


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

View raw message