Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Date: Fri, 1 Mar 2002 07:46:05 -0800 (PST)
From: <costinm@covalent.net>
To: Ant Developers List <ant-dev@jakarta.apache.org>
Subject: Re: TaskAdapter/TaskFactory/RuntimeConfigurable
In-Reply-To: <m37kow1ub9.fsf@bodewig.bost.de>
Message-ID: <Pine.LNX.4.33.0203010719050.2082-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On 1 Mar 2002, Stefan Bodewig wrote:

> * I feel that some of the proposals are trying to do too many things
> at the same time and therefore get problems being accepted as a
> whole.  This seems to be true in particular for antlib and embed, but
> I may be wrong.

I agree on antlib :-). In embed I just placed 3 different proposal
togheter ( instead of creating 3 dirs ), they are independent.
 
> In Costin's case, the changes that make ProjectHelper pluggable are
> probably not controversial at all while Peter will veto any proposal
> that mentions class loaders (I'm exaggerating on the last bit).

None of my proposals are touching class loaders directly - the 
task factory would enable someone to plug in something that implements
an arbitrary policy - like mp3 can be used to listen copyrighted
music :-) ( that includes a plugin implementing antlib behavior,
one implementing mutant or myrmidon's - and we can evaluate
them and/or use them in ant1.5 before deciding if we want any
in a future release )
 
> I'd love to see a project builder - whatever you want to call it -
> that is namespace aware tommorow rather than in six months.

That raises another proposal - enhancing the current ProjectHelper
to be namespace aware is trivial - but will require SAX2. The ns
information will just be passed to createTask and maybe stored/made
available - but if the TaskFactory gets accepted, it's create method
takes the ns param, so you can implement any fancy things there.

> * I don't see any harm with a task factory.  But let's look at the
> different pieces separately.

I'm working on another round on the TaskFactory - I'm combining it with
Role from antlib, to make it support Types as well. This one is
very tricky and I want to do it right, the factory can return
an adapter ( for both task and type - the second will help the
filter proposal ), and I want to give a bit more flexibility
 to the adapter.

> * I agree with Conor's comments about AntBean.

I agree too. I'll drop AntBean and make some smaller enhancements in
Project to make sure it's easy to just embed it directly.
 
> * I don't know why Costin thinks that a -1 needs to be seconded.

Sam can explain better the rules on -1.
>From my understanding:
- a veto must follow some rules to be valid
- it must be on a code change
- it must have 'valid' arguments. Anyone can challenge the validity,
and that requires a second opinion - another commiter that 'seconds'
the veto's arguments.
- it must propose an alternative solution ( and volunteer for the
implementation ).

http-dev has few examples, check the archives :-) The intention is
to prevent abuses, the veto is too powerfull. 

In our case - Peter arguments were that enhancing TaskAdapter to 
support beans with arbitrary-named methods ( like pre-existing
beans ) was that it's not generic enough ( but specific to 
one project ) - I think it's a common problem. Also that it
can be done in a task - and I think this is incorrect, since
TaskAdapter is hardcoded. 

Regardless of what me and Peter things, if a second commiter
agrees those are valid reasons the veto stands. At this moment
it seems it doesn't - so I'll go back to work on this :-)

Costin


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