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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
