ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <j_a_fernan...@yahoo.com>
Subject RE: [VOTE] Ant2 codebase adoption process
Date Wed, 23 Jan 2002 10:22:41 GMT
Guys and gals,

I think it is too soon to be making decisions about
one or the other. Pete has had myrmidom out for quite
a long time, but quite little info outside of code has
he provided. On the other hand, mutant just showed up
two days ago, fantastic introduction, but I do not
think anyone has had time to digest it, or try it, or
had time to think on what ideas are good or bad or how
extensible, flexible, or whatever this proposal is.

I think we need to give the proposals some time to
mature before we come with an axe and start chopping
things down and commiting ourselves to one or the
other.

I want to know more about mutant's vision of
integration with other tools, and how the separation
between XML and project model that it defines is
envision for tools to use. 

For example, what is the meaning of <ref/> if projects
are not comming from XML sources (can a tool stil
connect the models programmatically)? Actually, can a
tool build the model programatically without using
XML: is there a public API for bulding the model? I
have more questions and some may trigger changes in
the proposal, or may be already answerd by it.

Anyway, those are my thoughts,

Jose Alberto

 --- Adam Murdoch <adammurdoch_ml@yahoo.com> wrote: > 
> 
> > -----Original Message-----
> > From: costinm@covalent.net
> [mailto:costinm@covalent.net]
> > Sent: Wednesday, 23 January 2002 3:41 AM
> > To: Ant Developers List
> > Subject: Re: [VOTE] Ant2 codebase adoption process
> >
> >
> > On Wed, 23 Jan 2002, Conor MacNeill wrote:
> >
> > > The obvious candidates. IMHO are myrmidon and
> mutant. Other candidates
> > > may emerge in the discussion period. I do not
> believe we should include
> > > Ant 1.x as an option but again let us discuss.
> >
> > I think Ant1.x should be an option ( because
> that's what I would vote
> > for).
> >
> > I'm not an active ant commiter curently, but if my
> vote still counts
> > it'll be -1 on any candidate that doesn't have a
> clear backward
> > compatibility plan built into the design - i.e it
> should be able to run
> > most existing ant tasks and provide wrappers
> between the new APIs and
> > the old ones ( like xalan compat package for
> example ).
> >
> >
> > > [+1] Timetable - vote on or shortly after the
> 6th Feb
> > >
> > > [-1] Codebase adoption is by majority approval
> >
> > I don't think the vote should be on a codebase,
> but broken by
> > features/patterns ( allowing to select by vote
> what's best in
> > the 2 codbases ). This would also require the 2
> codebases to provide a
> > clear list of 'what's different from ant1 and why'
> - especially in
> > build.xml semantic and the task interface.
> >
> 
> This is an excellent idea.
> 
> We would choose the common features from each
> proposal, and put them
> together in a single source tree.  This tree would
> serve as a reference
> point for ant 2 work, and would contain features
> that ant-dev have reached
> consensus on (to some degree).
> 
> Proposals would still be spun off this reference
> tree.  However, they stop
> being proposals like "here's how I reckon Ant 2
> should work", and start
> being feature-based.  Such as, a proposal for a VFS,
> or how the classloader
> hierachy should work, or an extension to the typelib
> descriptor.
> 
> These smaller, better focused, proposals would be
> far easier to evaluate and
> roll back into the reference tree.  This way, Ant 2
> moves forward, people
> have a reference point to work against, yet are
> still free to experiment.
> 
> To kick start the whole process, it would be
> excellent if the owners of
> mutant and myrmidon were willing to be involved. 
> That would mean helping
> identify and extract common features, and using code
> from the reference tree
> as it becomes available.  This would be an iterative
> process:
> 
> * Pick a feature.
> 
> * Model it with an interface (or file format, or
> whatever - something
> shareable).
> 
> * Extract an implementation from one or both of the
> proposals into the
> reference tree.
> 
> * Refactor the proposals to use the interface, and
> optionally, the
> implementation from the reference tree.
> 
> * Repeat.
> 
> Peter, Conor, What do you reckon?  It would be a
> shame for the two proposals
> to sail off in their own directions.
> 
> 
> Adam
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:ant-dev-help@jakarta.apache.org>
>  

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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


Mime
View raw message