[EMAIL PROTECTED] 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.
Hmmm...
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.
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.
sure.
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.
There is a similar thing in cocoon that we just did that we called InputModules.
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
{request:username}
{sitemap:myproperty}
{context:mystuff}
Basically what you are saying, right? Can we make some common functionality? Hmmm...
-- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
