ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: [MEETING] January 12th. SF Bay.
Date Tue, 19 Dec 2000 22:09:29 GMT
I will be out of the States at the time.
And in the process of moving to Europe, maybe in the future we could
use some Voice Chat site or do the webcast thing.

Jose Alberto


> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Tuesday, December 19, 2000 1:10 AM
> To: ant-dev@jakarta.apache.org
> Cc: ant-dev@jakarta.apache.org
> Subject: Re: [MEETING] January 12th. SF Bay.
> 
> 
> At 11:30  18/12/00 -0800, Jon Stevens wrote:
> >on 12/18/2000 10:59 PM, "Peter Donald" <donaldp@apache.org> wrote:
> >
> >> Be carefule how you put this. Look at the CVS tree and the 
> people who have
> >> actually made patches against ant in say the last 2 
> months. I suspect you
> >> will be the lone committer who is at the meeting that you 
> say aims "to
> >> report to the Ant-Dev list a consensus about the general 
> direction we
> >> should take to move things further". Do you think this is 
> appropriate ? ;)
> >
> >So, are you saying that you don't want to meet?
> 
> I am saying I can't ;)
> From where I am in the world it would cost me about $2500 to 
> get to US and
> back + expenses. I assume this is the same for Connor aswell 
> as he also
> lives in Australia (unless he can swindle it on Company time 
> ;]). Whether
> other contributors - Stefan looks like hes from germany ???, 
> Glens from
> Canada?? and Sam Ruby look slike he is from the US can afford the trip
> should also be considered. 
> 
> While you may not intend to exclude others you do by virtue 
> of location - I
> really don't know of anything that wouldn't be better 
> discussed on lists.
> Closed doors and exclusive access is not good for opensource IMHO ;)
> 
> 
> >> The ideas about Ant2.0 (at least the non-revolutionary 
> ones) are easily
> >> accessible in archives. No real revolutionary ideas have 
> been discussed
> >> (except for two latest proposals) so I am not sure what it 
> is that you
> >> intend to come to a consensus about.
> >
> >"(except for two latest proposals)"
> >
> >Are you just ignoring those then?
> 
> No but I don't think kicking about ideas will be enough - at least for
> AntFarm. It is something that requires examining use case. 
> While this may
> be doable in a meeting place it would be better served if 
> people went out
> and examined their own build files and how it would be 
> useful/unuseful in
> those cases. In which case it is as easy to communicate to 
> the list as it
> would be in person.
> 
> It would be unfortunate if the rest of us were to miss out on 
> the input
> because it wasn't distributed to us.
> 
> >At this point, with the hundred page emails of everyone 
> saying 50 different
> >things, I'm not sure how that is clear to anyone.
> 
> look back to the archives then ;)
> 
> >> What makes you think that the current ideas about Ant2.0 
> product is a
> >> mishmash. I think the aims/designs are relatively clear - the
> >> implementation is completely fuzzy but there is little use 
> hashing it out
> >> when only one of the developers who is proposing a 
> revolution is present.
> >
> >Ok, where is a single clear well defined functional 
> specification for Ant
> >2.0 that everyone agrees on? Sorry, I missed it.
> 
> From what I can tell in point form it is;
> * namespace support so different concerns can occupy 
> different namespaces
> from ant (thus SAX2/JAXP1.1)
> * Java2
> * The ability for GUI/IDE tools to integrate easily with object model
> without reinventing the wheel and writing their own parser 
> (which antidote
> was forced to do). Two suggested solutions were allowing GUI 
> developers to
> extend object model (ie GUITask extends Task) or to have Task 
> as interface
> (ie GUITask implements Task). This way the GUI tasks could be W3C DOM
> Elements, have property vetoers/listeners etc.
> * Fully interpreted at runtime. This almost requires some form of
> abstraction/proxy that stands in place of tasks till it is 
> interpreted.
> This can be hashtables/simple dom-like model/whatever
> * provide utility classes to aid in building tasks. ie like up-to-date
> functionality abstracted
> * make ant-call a low cost operations so it can certain
> optional/template-like operations
> * allow facilities to build projects from multiple sources. 
> ie CSS+xml or
> XSLT+ XML or database or from inside jars or normal build.xmls etc.
> * remove magic properties if at all humanly possible
> * make all tasks consistent and remove all deprecated methods
> * move to anakia/stylebook for docs
> * allow documentation to be stored in .tsk jars
> * allow tasks to be loaded from jars. tasks should be 
> indicated by either
> xml file in TSK-INF/taskdefs.xml or manifest file.
> * remove as much dependency on native scripts as possible.
> * clean object model (ie Project/Target/Task)
> * good event model to integrate well with IDE/GUI/whatever
> * better scripting/notification support so the hooks are 
> available to send
> notifications at certain times.
> * allow all datatypes to be defined anywhere
> * make usage of particular filters/filtersets explicit in copy tasks
> * make facade tasks for things like javac (JikesImpl, ModernImpl etc)
> * seperate tasks into .tsk jars somehow. (Probably via 
> function - ie java
> tasks, file tasks, ejb tasks).
> * unify multiple similar tasks to use similar forms (ie all 
> the javacc type
> tools)
> 
> The above are all things that are relatively certain (ie I 
> don't know of
> anyone who objects to them). If any of the points are unclear 
> ask me and I
> will try to clarify. Theres possibly quite a few things that 
> I missed out
> on because I take em for granted - if there is anything else 
> that you think
> should be in above list feel free to add it. (or expand above points).
> 
> Now there is a bunch of "controvertial" points. By 
> controvertial I mean not
> everyone agrees or else there has not been enough comments to to judge
> reception
> * unify the namespace of all data types (ie properties + filesets +
> patternset + filtersets). Currently duncan opposes this
> * make it possible to reuse taskengine for other things. ie 
> Installshield
> type app, my cron-server and other task based operations. Currently no
> committer other than me has expressed positive or negative 
> thoughts about this
> * make separate build files easy (ala AntFarm) and importing different
> projects a breeze
> * create the concept of workspace so that projects can be 
> built in a DAG
> and thus enable projects like catalina/tomcat to have an easy build
> process. It also helps CJAN to a lesser degree and would 
> partially solve
> the JARs in CVS thing.
> * provide support for CJAN
> * provide support for non-hardwired (ie loadable) converters.
> * provide support for non-hardwired (ie loadable) datatypes.
> * provide datatypes through property tag and remove need for 
> seperate free
> standing entities. ie
> <property name="foo">
>   <fileset dir="blah">
>    <include name="*/**.java" />
>   </fileset>
> </property>
> 
> Theres quite a few more of these but they can't really be 
> discussed until
> some of the other base components has been formalized. I have 
> also left out
> some of the more freaky ideas that have been proposed as they haven't
> elicited much comment but that should give you basic idea.
> 
> >p.s. I removed Brian from the CC because he doesn't need the 
> extra email
> >discussion I'm sure.
> 
> oops soz - didn't realize he was cc'ed ;)
> 
> Cheers,
> 
> Pete
> 
> *------------------------------------------------------*
> | "Computers are useless. They can only give you       |
> |            answers." - Pablo Picasso                 |
> *------------------------------------------------------*
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> 

Mime
View raw message