From: "Conor MacNeill" <[EMAIL PROTECTED]>
> I agree with Jose Alberto that the parser (currently ProjectHelper)
> should not have any "special cases", such as the current test 'if name
> == "property" doBlackMagic()'. However there is a limit to that. There
> are some constructs in the buildfile which should be recognized and
> handled by the parser and not delegated. This is necessary because some
> of these constructs deal with fundamental core datastructures. I agree
> with Peter that we want clear separation between core components and
> user tasks through a clear well-defined interface. I believe this is
> necessary to support a proper classloader hierarchy - there will be core
> classes that cannot be made available to tasks, without coupling
> classloaders and the nightmares that brings. We need something similar
> to the servlet engines which carefully structure their classloader
> hierarchies and, require clear separation of classes (responsibilities).
>
This is good point. ClassLoader management needs to be looked again.
When I was building <antlib> I noticed some extrange things in the
classloader code that I could not understand. Like:
1) ClassLoader variable of Project seem to be always initialized to null.
2) AntClassLoader default parent taken from AntClassLoader.class instead of
the value on Project.
It certaintly looked funny to me.
> I haven't look in detail at Jose Alberto's <antlib> proposal, but my
> concern, from an Ant2 perspective, is how it works within a defined
> classloader hierarchy. There will just be some classes that it needs to
> use that, being in "user" space as it were, to which it will not have
> access. Perhaps this implies a need for an extension mechanism that
> allow some tasks to extend the core operation but which are loaded
> within the core's classloader, or a child classloader - I'm not sure at
> this stage. Is it flexibility syndrome or a sensible design for
> extensibility? That is probably personal opinion. We could leave it out
> to start with and then add it in when the need arose.
>
In my current implementation, each library is loaded on its own classloader
with parent set to the "Project" classloader (or what I thought was the
equivalent
of that given the way classes are used).
There is also support to allow a library to be loaded "oncurrent" classloader.
For starters this assumes that the library is already in the classpath and you
just
want to process the descriptor information. This is there in particular to
support
CORE tasks to be loaded in whatever it is the initial classloader for ANT.
As I think I mention on a different thread, what I would like to do is for the
entire
of ANT code (as much as possible) to be loaded using our own ANT controlled
classloader on which we can do things like extend the path as more jars are
required.
Except for perhaps one Main class, all the rest of the code should be loading
under our control, that includes XML stuff, Project, etc.
> We have agreed to unify the namespace of properties and other "types"
> but not necessarily the contructs used to declare those elements.
>
>
> >
> > (2) Allow all tasks to be defined at the same level as <target> (I
> > don't know whether he remembers it, but Sam Ruby proposed this about
> > fifteen months ago 8-).
>
>
> Unify datatypes and tasks and allow this: +0
>
As the examples from Stefan demonstrate there are other things than
properties/datatypes
that make sense at project-level. I do not believe on making each one of them
just
another special feature of the ANT "language".
>
> >
> > (3) Allow all tasks that implement a given marker interface to be
> > defined at the same level as <target>s (Jose Alberto Fernandez
> > proposes this and has already supplied a patch that enables this in
> > Ant 1.x).
>
>
> These aren't tasks for classloader/separation reasons. +0 on a core
> extension concept implemented this way.
>
To make clear, the objective here is to be able to specify whether a task in
question
can be used at project-level or not. This is completely independend of any core
extension/
or classloader issues. Those should be managed by <antlib> or the descriptors.
Also notice that today, when you declare a <type> you implicitly are allowing
this
user defined object to be used at Project-level. Hence, providing similar
access to
user defined tasks is not a big extrapolation. BTW I have no problem declaring
such tasks using a construct other than <type> or <task> in the descriptor.
My point is that 3rd party libraries should be able to define them, just as the
core libraries can.
Jose Alberto
