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 21:35:54 GMT wrote:
> On Mon, 15 Jul 2002, Nicola Ken Barozzi wrote:
>>>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 :-|
> If someone names a task "test:task", and uses <test:task ... /> it'll
> work with SAX1, but it'll fail with SAX2 ( since ':' is reserved for 
> namespaces ).
> The user will have to either modify the task name or use a SAX1 parser.

Ah, ok.
I supposed you had defined the test namespace ;-)

>>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... :-?
> That's the 'loader hierarchy' solution - i.e. not include optional.jar
> in lib. It seems Peter can't accept this solution because it would brake
> some of his tasks that don't use the parent class loader and expect
> optional.jar tasks to be in the CLASSPATH.

Ahhh, now I get it.

> In the standard 1.5 distribution optional.jar is included in lib,
> and the user can't use taskdef to load junit in a separate loader.
> You either remove optional.jar from lib ( or at least the tasks 
> that depend on other jars ), or you play tricks with the classloader.

I did the first.

>>>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? ;-)
> No, ant better integrated with an application that embeds it. 


>>>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?
> If you want ant to have to access properties from an embedding app,
> you either set all the properties explicitely or allow ${} to
> extract them on demand. 

Ah, ok, pushVSpull ;-)

>>>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.
> XmlPropertiy is just one example - there are many other tasks ( like the
> testing ones in anteater, etc ) that could benefit from this.


>>>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 
> That's one of the targets I have. But any other property source can be 
> plugged.

There is a similar thing in cocoon that we just did that we called 
In the Cocoon sitemap, we have things that are similar to Ant 
properties, and we used to have them in a Hashtable (well, not totally 
true but kinda ;-)
Now we have "Modules" to access properties, ie

Basically what you are saying, right?
Can we make some common functionality?

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