On 1/8/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Fri, 29 Dec 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:
> * 1.8
> - add classpath manipulation (classloader task)
could that be done as an antlib or does it require support inside of
the Ant core engine?
We need to fix the coreLoader stuff currently in ant.
This can be used to load in tasks/types and xml namespaced
loaded antlibs.
To work properly this needs:
* to use a copy-on-write mechanism - so that classloaders do not get modified
and so that sub-projects do not modify the core-loader of the main
project.
* inform ant-core ComponentHelper xmlns antlib autoresolver that the
coreLoader has
changed.
* works when using antcall, i.e. multiple calls do not change the coreloader.
* may need to optionally allow the coreloader to be not inherited in
sub-projects.
(i.e. an extra inherit arg - I think that by default the coreloader should be
inherited - this is not the default for references).
Doing this will solve a number of issues with optional packages
and with useablily of antlibs.
I am thinking of replacing the current oata.taskdefs.ClassLoader
with a task that *just* controls the coreloader.
Any other idea is to provide a generic per-task task/type loader. This
is done by hand at the moment for <junit> and <script>.
I have looked at others, but it is tedious and error-prone as
each optional task is different - some currently use the classpath
for different things - <jdepend> and <xslt> for example, and some
do not have a <classpath> but do have a large main task - <sshtask>/<scp>.
> - add logic/controlflow features from jsp/ant-contrib (for, if,
> while, try, var etc)
inside of Ant's core? I'd prefer an antlib, which would lead to the
question why we'd need one separate from ant-contrib, of course.
> - allow javascript and jruby to create tasks/types natively
what changes would be required for that?
> - if/unless attributes with primative EL (expression language)
> (ie if="${property.not.present}" will work as
> if="property.not.present")
can't we do that with custom PropertyHelpers, in some wierd way?
It would be better do this in in core ant. (I have been using facelets,
JSF and SEAM in a prototype and having EL and control tags and
attributes (repeat, if, for, rendered="#{not empty aComponent}") is
very pleasent).
Some work needs to be done to allow ant-core to be configured
to use this. I do not like the current custom PropertyHelpers:
* it to too drastic - replacing completly the property handler
* sub-projects are currently not supported
To be usefull, I think that EL should be part of ant-core, perhaps
with a task to enable/disable it.
> * 1.9
> - integration with ivy/maven for dependence
what kind of integration beyond what Ivy currently provides do you
envision?
I am not too sure - I do not have BroadBand at home
at the moment, so I cannot use maven to get a feel of
how one can use it. However I have noticed a lot of
projects have started to use it, and as far as I can
see it provides a number of usefull features
- dependence
- site documention
The ivy antlib may provide the dependence support
needed - but I think that ant will have to provide
an easy inbuilt way to download, install and use antlibs,
especially the antlibs on the ant site.
> * 2.0
> - remove need of xml
alternatives to XML could and should be possible with custom
ProjectHelpers, at least we should make it possible prior to 2.0
We have mentioned using custom ProjectHelpers, but I have not
seen any....
Peter
(which also requires feeding the hungry and preventing the world
climate from becoming even more troubled).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
