ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: pluggable ProjectHelper
Date Thu, 21 Feb 2002 16:29:03 GMT
I don't have the brain bandwidth right now to really dig in and comprehend
the changes you've made, but I'm +1 on the extensibility ideas you've said
will be possible.

Will you be making some prototype (or production!) app that takes advantage
of these added capabilities?  Please share it if at all possible.

    Erik


----- Original Message -----
From: <costinm@covalent.net>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Thursday, February 21, 2002 11:01 AM
Subject: Re: pluggable ProjectHelper


> On Thu, 21 Feb 2002, Peter Donald wrote:
>
> > Hi,
> >
> > Would you mind making all those icky protected variables private :)
>
> No problem, I'll do that.
>
> If nobody is -1 for the patch, I would commit it (I'll wait another day
> for comments). An additional improvement I want to make is to add a
> createProject() method in ProjectHelper and use it instead of
> new Project().
>
> That would allow a helper plugin to better embed ant.
>
> There are many use cases:
> - an IDE using ant, that may construct the targets/tasks on the fly, from
> internal data - without using XML at all.
>
> - embedding ant in a webapp or SOAP service, and using the POST
> data to drive it.
>
> - someone using ant for 'scripting' or some other evil use, and using
> a plugin that supports modifiable variables ( hopefully with a proper
> declaration and leaving the 'normal' properties unmodifiable ).
>
> I would also like to commit some changes to the Ant task, making
> it useable as an independent component that would jumpstart ant.
> ( I already wrote an 'EmbededAnt', by refactoring Main, but Ant task
> seems a much better place to do that ).
>
> I'll mark all new properties as 'experimental' and make sure the
> current behavior is preserved, of course ( and send a patch for
> review before commiting )
>
> Costin
>
> >
> > On Thu, 21 Feb 2002 11:47, costinm@covalent.net wrote:
> > > The goal of this patch is to allow a different XML processor
> > > to be plugged in and used.
> > >
> > > The current processor has a number of limitations ( lack of
> > > namespace support, etc ) - but the main benefit for this
> > > patch is that it allows new ideas to be used without
> > > affecting the whole thing.
> > >
> > > How it works:
> > > - the current parser is used as default.
> > >
> > > - a user can set a system property or just include an
> > > alternative xml processor in the classpath, and this
> > > will be detected and loaded instead of the default.
> > > ( same pattern as in jaxp, common-logging, etc to
> > > find a Helper implementation )
> > >
> > > - all helpers are supposed to support the original
> > > behavior and be backward compatible. Of course, the user
> > > may ignore this and use a completely different model,
> > > or have the behavior customized based on some namespace,
> > > etc.
> > >
> > > Costin
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message