text: On 1/8/07, Stefan Bodewig <bodewig@apache.org> wrote:
  > On Fri, 29 Dec 2006, Peter Reilly <peter.kitt.reilly@gmail.com> 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>.
  >
  > > -?
  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).
  >
  >