ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 19:41:46 GMT
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.


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

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.

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


> > 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 
> http://jakarta.apache.org/commons/jxpath/index.html.

That's one of the targets I have. But any other property source can be 
plugged.

Costin


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message