ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: Proposed roadmap
Date Sat, 13 Jan 2007 16:04:13 GMT
On 1/8/07, Stefan Bodewig <> wrote:
> On Fri, 29 Dec 2006, Peter Reilly <> 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
* inform ant-core ComponentHelper xmlns antlib autoresolver that the
coreLoader has
* 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
  (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....


> (which also requires feeding the hungry and preventing the world
> climate from becoming even more troubled).
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message