> -----Original Message-----
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 3 May 2006 6:44 AM
> To: Ant Users List
> Subject: Re: Asking for new feature: Self-Discovery of
> service to make Ant a real extensible system
>
> Huxi LI wrote:
> > Very interesting dicussion in this thread. And it seems most people
> > are in favor of using namespace as a single mechanism. It
> is true that
> > using namespace is the most simple way to resolve conflict, but I
> > insist that it is not the most transparent solution for
> users. That is
> > because, IMHO, uniform acess principal is important in many case,
> > using antlib destroy such beauty. As a simple example, when ant is
> > integrated in Groovy using the AntBuilder, we can seamlessly invoke
> > any Ant tasks and datatypes by using simple method call such as:
> >
> > ant.echo("Hello World")
> >
> > But using namespace destroys such uniform access principal
> provided by
> > the core project comonents, and so it destroy the seamless
> integration
> > with groovy as well. Anyway, thanks all for the active discussion.
> >
> > HL
> >
>
> I agree, namespaces lack beauty. Indeed, they are ugly and
> painful to work with. But once you have task/type autoload,
> you have naming conflict. xmlns is the "official" way to
> isolate stuff from different xml languages,
On this I agree.
> and, despite its many failings, does work in build files.
Due to the structural limitations inherent in the Ant 1.X model of system +
directives + implementation.
I.e. wherein Ant 1.X is:
(a) the manager of antlib deployment,
(b) a source of underlying JVM services (e.g. copy etc.)
(b) and, a collection of incomplete optional extensions (e.g. junit);
> The big penalty is now you have xmlns declarations which need
> to be copied along with task declarations for cut-and-paste editing.
But only true in the case of the current Ant Main solution (i.e. the default
Ant embedded project deployment scenario).
Break out the above 1.X aspects and you end up with separation of some very
different concerns that would go a long way to defining what Ant 2.X should
be about. In this scenario you would end up with core (jvm dependent) tasks
defined in a specific namespace; anything with dependents declared in
namespaces that included qualification of dependents; and a very small
kernel that handled namespace qualifies library deployment in a manner
independent of things like an ${ant.lib} directory (which at the end of the
day is nothing more that a very low-level and primitive deployment strategy.
In effect, Ant 2.0 would be:
a) a build manager
b) a framework for qualified antlib deployment
c) a set of jvm version qualified services
d) a bunch of qualified optional services
Where 'qualified' means going beyond 'antlib' as it is defined today to
include
a) the current task/data type definitions
b) preferably a deployment meta-model
c) and probably a classloader solution (encapsulating build, runtime, test
and
and integration phases) enabling dynamic extension (independently of
policy
handwaving)
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
