Re: TaskAdapter/TaskFactory/RuntimeConfigurable

[Stefan Bodewig <bo...@apache.org>]

Some random thoughts on all the mails in this thread:

* 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.

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).

I'd love to see a project builder - whatever you want to call it -
that is namespace aware tommorow rather than in six months.

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

* I agree with Conor's comments about AntBean.

* I don't know why Costin thinks that a -1 needs to be seconded.

* If a task factory changes the class loader semantics but the core
remains unaffected, it seems that both Costin and Peter can have their
cake.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: TaskAdapter/TaskFactory/RuntimeConfigurable

[co...@covalent.net]

On 1 Mar 2002, Stefan Bodewig wrote:

> > None of my proposals are touching class loaders directly
> 
> I am aware of that, you said so in a separate mail.  You just
> shouldn't even mention them to support your changes 8-)

I prefer full disclosure, and besides most people can figure
that for themself :-)

> > That raises another proposal - enhancing the current ProjectHelper
> > to be namespace aware is trivial - but will require SAX2.
> 
> I know, it's just that I've never come around to doing it myself and
> you promised to do it while refactoring ProjectHelper.

Yes, the only big change in ProjectHelper is to change the signatures
to use SAX2. The issue is how to pass/use the ns info - and that's
where TaskFactory helps ( they are separated proposals, but help 
each other ) 

I am planning a bigger refactoring of ProjectHelper ( merging it
with xmlmapper and some ideas from axis deserializer ), but
that's not for 1.5 and will probably be in commons. ( I'm still
at design stage, did few experiments but I'm not yet happy ).


> One of my goals with name space support is that we can start to ignore
> certain namespaces (those that we do not understand) so people can
> extend Ant's build file syntax to to additional things in the build
> files.

+1

Again it's something that can be fine-tuned with the TaskFactory,
but ignoring seems the best default for unknown ns.
Unqualified names should remain reserved for ant1 tasks. 


> Think embedding gump project description in the build file for
> example.  Adding extra documentation inside the build file.  Adding
> information for a build file writing GUI. ...

In addition, namespaces should be used to group optional 
tasks ( and even for core tasks ). But the current 'flat'
model must remain the default for backward compat.


> > - it must have 'valid' arguments. Anyone can challenge the validity,
> > and that requires a second opinion
> 
> Oh, I see where you get your second -1 from.  That's not been my
> understanding of valid, but I guess a seconded explanation has to
> count as valid.

Both the 'veto' and the 'invalid veto' can be abused - this seems 
like a good compromise and I'm pretty sure this is the rule.

Costin




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: TaskAdapter/TaskFactory/RuntimeConfigurable

[Stefan Bodewig <bo...@apache.org>]

On Fri, 1 Mar 2002, <co...@covalent.net> wrote:
> 
> None of my proposals are touching class loaders directly

I am aware of that, you said so in a separate mail.  You just
shouldn't even mention them to support your changes 8-)

>> 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.

I know, it's just that I've never come around to doing it myself and
you promised to do it while refactoring ProjectHelper.

> 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.

One of my goals with name space support is that we can start to ignore
certain namespaces (those that we do not understand) so people can
extend Ant's build file syntax to to additional things in the build
files.

Think embedding gump project description in the build file for
example.  Adding extra documentation inside the build file.  Adding
information for a build file writing GUI. ...

[on -1s]

OK, a -1 is only a veto if a certain decision requires consensus,
which are not too many things.

> - it must have 'valid' arguments. Anyone can challenge the validity,
> and that requires a second opinion

Oh, I see where you get your second -1 from.  That's not been my
understanding of valid, but I guess a seconded explanation has to
count as valid.

> 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. 

Let's see the factory and argue on the basis of what it can do, not on
what it could be abused for.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: TaskAdapter/TaskFactory/RuntimeConfigurable

[co...@covalent.net]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>