ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: TaskAdapter/TaskFactory/RuntimeConfigurable
Date Fri, 01 Mar 2002 15:46:05 GMT
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 :-)


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message