--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Oct 2008, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > I am thinking a less invasive approach would be:
>
> Sounds good to me.
>
> > 1. Allow arbitrary properties of a Target object
> to
> > be set using IntrospectionHelper.
> > 2. Delegate Target instantiation to Project.
>
> Why?
Precedent. The Project instance is responsible for
creating its own subproject Project instances; this
seemed similar.
>
> I have a toy project that I hope to be pushing into
> the sandbox sooner
> or later which contains a custom ProjectHelper. It
> heavly relies on
> the ProjectHelper to be able to create its own
> subclass of target.
>
I see; however let me ask you this: which is more
straightforward, creating a custom ProjectHelper or
extending Project and/or Target? I guess the answer
depends on how comfortable you are with the SAX APIs.
Personally, for me, it's the latter. Without tipping
your hand, can you give any more information about
what requirements drove you to implement your custom
ProjectHelper?
> > 3. Define an ant.project.class magic property to
> > easily allow the user to specify an extended
> Project
> > class to use.
> > 4. EasyAnt has its own Project, Target, and
> Executor
> > implementations that know about phases.
>
> If EasyAnt used a ProjectHelper of its own, it
> probably could get away
> without a custom Project. A custom Executor may be
> a good idea,
> though.
>
> EasyAnt would need its own wrapper script or an
> invocation would
> become cumbersome, though.
How is a custom Project class(name) more cumbersome to
configure than a custom ProjectHelper?
br,
Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
