You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <pe...@apache.org> on 2002/03/01 12:23:47 UTC
Re: cvs commit: jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/components/deployer DefaultDeployerTest.java TestConverter1.java
On Mon, 25 Feb 2002 22:02, Adam Murdoch wrote:
> > -----Original Message-----
> > From: adammurdoch@apache.org [mailto:adammurdoch@apache.org]
> > Sent: Monday, 25 February 2002 8:43 PM
> > To: jakarta-ant-cvs@apache.org
> > Subject: cvs commit:
> > jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/componen
> > ts/deployer DefaultDeployerTest.java TestConverter1.java
> >
> >
> >
> > Log:
> > Replaced usage of Avalon Context with Myrmidon specific Context:
>
> I wasn't really planning to do this, but hooked into it when I found that
> the converters weren't being handed a TaskContext in the new places where
> conversion is happening. It wasn't till I was almost done that I
> discovered TaskContextAdaptor.resolve(). Too late by that stage, the
> changes were all mixed up in the other stuff, so I kept going.
Blech. Really don't like this. Complicates the task API for little benefit
IMHO. If we were going to bind to ants specific notiong of a context then we
should bind directly to TaskContext.
> Personally, I prefer this approach, rather than adapting back and forwards
> between TaskContext and Avalon Context. Resolvable and Context are just a
> bit too general for my taste. However, I can roll this particular change
> back, if there's some compelling reason to go with the Avalon Context.
+1 to a revert. It is ugly now but I plan to rework this in the future to
make it easier to use. The main reason it is general is so that it it can be
used outside of ant with minimal interlinking. Similar to how the Converter
architecture is largely (all?) decoupled from ant/avalon atm.
So it may not be perfect now but I don't think creating a new Context object
is the correct answer.
--
Cheers,
Pete
When a stupid man is doing something he's ashamed of, he always
declares that it is his duty.
George Bernard Shaw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/components/deployer DefaultDeployerTest.java TestConverter1.java
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Mar 2002 23:01, Adam Murdoch wrote:
> > Blech. Really don't like this. Complicates the task API for
> > little benefit
> > IMHO.
>
> How do you mean? The task API hasn't changed at all.
You have added an extra layer of inheritance which doesn't really buy us
anything. Thats the main reason I made things it not extend Avalons Context.
> > If we were going to bind to ants specific notiong of a
> > context then we
> > should bind directly to TaskContext.
>
> We're bound to a super-type of TaskContext. A very general super-type.
> Nothing terribly Ant specific about it, except for the package it happens
> to be sitting in at the moment.
And the fact that it uses TaskException.
> How is this any different to binding to an
> avalon specific notion of a context?
2 uneeded methods. Direct tie to the Task API. If we are going to do this
there is no point to having a super class because we may as well use
TaskContext directly.
--
Cheers,
Pete
------------------------------------------
I just hate 'yes' men, don't you Smithers?
------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/components/deployer DefaultDeployerTest.java TestConverter1.java
Posted by Adam Murdoch <ad...@yahoo.com>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, 1 March 2002 9:24 PM
> To: Ant Developers List
> Subject: Re: cvs commit:
> jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/componen
> ts/deployer DefaultDeployerTest.java TestConverter1.java
>
>
> On Mon, 25 Feb 2002 22:02, Adam Murdoch wrote:
> > > -----Original Message-----
> > > From: adammurdoch@apache.org [mailto:adammurdoch@apache.org]
> > > Sent: Monday, 25 February 2002 8:43 PM
> > > To: jakarta-ant-cvs@apache.org
> > > Subject: cvs commit:
> > >
> jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/componen
> > > ts/deployer DefaultDeployerTest.java TestConverter1.java
> > >
> > >
> > >
> > > Log:
> > > Replaced usage of Avalon Context with Myrmidon specific Context:
> >
> > I wasn't really planning to do this, but hooked into it when I
> found that
> > the converters weren't being handed a TaskContext in the new
> places where
> > conversion is happening. It wasn't till I was almost done that I
> > discovered TaskContextAdaptor.resolve(). Too late by that stage, the
> > changes were all mixed up in the other stuff, so I kept going.
>
> Blech. Really don't like this. Complicates the task API for
> little benefit
> IMHO.
How do you mean? The task API hasn't changed at all.
> If we were going to bind to ants specific notiong of a
> context then we
> should bind directly to TaskContext.
>
We're bound to a super-type of TaskContext. A very general super-type. Nothing terribly Ant specific about it, except for the package it happens to be sitting in at the moment. How is this any different to binding to an avalon specific notion of a context?
> > Personally, I prefer this approach, rather than adapting back
> and forwards
> > between TaskContext and Avalon Context. Resolvable and Context
> are just a
> > bit too general for my taste. However, I can roll this
> particular change
> > back, if there's some compelling reason to go with the Avalon Context.
>
> +1 to a revert. It is ugly now but I plan to rework this in the future to
> make it easier to use.
Before we revert anything, perhaps it would be worth looking at how you are planning to rework this, so that we can start pushing it in that direction.
> The main reason it is general is so that
> it it can be
> used outside of ant with minimal interlinking. Similar to how the
> Converter
> architecture is largely (all?) decoupled from ant/avalon atm.
>
Sure, but there's a trade-off between *reusability* and *usability*. Too general is useless. Let's not get too carried away with making this stuff reusable.
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>