James,
To me ANTEATER should consist of just the following:
<project/>
<target/>
<taskdef/>
<datadef/>
<property/> //reluctantly
The core should not assume the existance of any task and every task
should be expressable with the services provided by CORE.
This means having a meaninful resolution of how magic properties work today
(i.e., "build.compiler").
It also means eliminating the magic "default.properties" files and moving
to tasklib definitions containing <taskdef> and <datadef> definitions.
<property>s I would like to just be considered as a <datadef> with no
special
capabilities, but I am not sure how "${}" expansion could be implemented.
Maybe "${}" should act on IDs and just consider property.name() as just
another
way to register an ID. With that "${x}" expansion is not more than the
toString() operation applied to the object whose ID is "x".
but I degress... The point is to give <taskdef> and <datadef> enough
expresive power such that there is no magic required for anything else.
Jose Alberto
> -----Original Message-----
> From: James Duncan Davidson [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 13, 2000 4:33 PM
> To: [EMAIL PROTECTED]
> Subject: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
>
>
> I'm going to start this mail with the admission that I've
> been in and out of
> this list too much over the past year. Ant started out as an
> idea on an
> airplane that got refactored a few times before coming to Apache. It
> actually was open sourced just a tad too early imho and could
> have dealt
> with a bit more rigor. Unfortunately, I haven't made the time
> that I've
> wanted to deal with Ant to this point and instead have been
> concentrating on
> internal matters at Sun wrt open source and XML specs. Some
> of you who know
> me personally know about the ins and outs of this. For everyone else,
> suffice it to say that I've been overloaded and distracted.
> Much gratitude
> is owed on my part to Stefan and Sam and Conor and all of you
> for continuing
> on just like Open Source should.
>
> However times they change. My involvement in this project is
> going to change
> substantially over the next few months. Yes, I've tried to do
> this before
> and failed. However, this time *will* be different. There are
> lot of reasons
> for this, some official and some very personal, but primary
> to this is that
> Ant is getting the attention I always wanted it to get (and
> never imagined
> to see) and I feel an obligation and a desire to see it
> through to the next
> level. I've had conversations with some of you about this --
> most notably
> Stefan while in London. Also, as I was giving my keynote at ApacheCon
> London, I was thinking to myself how amazing it was that Ant
> is now getting
> *so* much attention and that it was one of the real gems of
> The Jakarta
> Project. I also think it's clear that we need one more
> incompatible change
> -- an Ant 2.0 -- to take us to that next level. And, I've got
> more than a
> few ideas of how to get there. I've been itching to get them
> out, but it
> always seems that there is one thing or another blocking my
> time to do so.
>
> I've also been contacted by a major publisher that wants to
> do a book on Ant
> -- I'm not at liberty to discuss what publisher or schedules
> or anything as
> there isn't a contract yet, but suffice it to say that it would be a
> definitive definition of Ant and how to use it from a major respected
> publisher in the industry. This is an opportunity that I am
> most likely
> going to pursue, and it -- in combination with working
> towards an Ant 2.0 --
> is now making ant number 1 on my priority list. And yes, I'd
> even consider
> taking a leave of absence from my employer to do this -- I
> think that it's
> that important to me.
>
> Ok, so enough of the personal story -- here's where it
> affects this group.
>
> I'm in the process of writing up a proposal and playing with
> some source
> code thoughts for "AntEater -- a Proposal for Ant Core 2.0". This is a
> proposal for the core of Ant, and should be a solid base for
> a GUI and other
> things -- but I'm not going to enter into GUI land with this
> as there are
> better qualified people here for that if AntEater does get
> accepted. My
> intention is that the problems that the GUI folks have
> already seen are
> rectified.
>
> I'm doing this as "AntEater" as I want to play by the rules
> that I set down
> in the "Rules for Revolutionaries" document some time back in
> Tomcat-land.
> Even though I think that I've got the ideas and design to
> take Ant to 2.0,
> by no means do I think that they are the only way to get
> there -- and that
> they should trump everyone else's ideas. I'm not so arrogant
> to say that
> since I wrote ant, I control it's future and what should be
> called "version
> 2.0"-- that's not true -- it's the group of committers here
> that controls
> the future of ant.
>
> So, I'm pulling together my proposal and code base. And I'd
> be ready to
> release it to you in about a week's time -- except for the
> fact that I'll be
> out of touch of telephones and the internet from 11/18
> through 12/2. Given
> that I won't be ready before this happens -- and I want to be
> present to
> have a dialog about my proposal -- I'll be making it public
> to this group on
> Monday 12/4.
>
> I considered not saying anything about this until I get back
> into radio
> range -- however, given that there are other discussions
> about refactoring
> the internal data structures and what should go into a next
> generation Ant
> -- I wanted to make my intentions, and plan for those
> intentions, clear. It
> seems like the fair and right thing to do in this case.
>
> So, when I get back, I'll be making my proposal and I hope
> that you all will
> consider it as a future direction for Ant. To be clear, if
> you guys reject
> it, then we *will* play by the rules of the Jakarta Project
> and I'll keep
> pestering you about it, and will work with others on their
> ideas as well,
> until we do get to a real, solid, stable Ant 2.0.
>
> A rough overview of my thoughts that will be in AntEater --
> Lots and lots
> more detail will be present in my 12/4 drop:
>
> Solidification of the Project/Target/Task hierarchy. This
> is the core
> of Ant's model and it should be explicitly locked.
>
> A strict definition of the internal object model to
> enable scripting
> and GUIs for execution and editing. This object model is
> a reflection
> of the build.xml file -- and should be the object model used by
> the GUI and scripts directly. We shouldn't have multiple
> object models
> in place.
>
> A clear definition of how scripting (external or inline CDATA)
> can be used with Ant through the Task interface --
> keeping scripting
> clearly separate and yet making Ant infinitely malleable
> to scripts.
>
> A clear extension mechanism that makes sense on whatever platform
> Ant is run on. For example, on unix Ant should look in
> ~/.ant/tasks:
> /usr/local/ant/tasks:$INSTALL_DIR/optionaltasks. On MacOS
> X, it should
> look in places like ~/Library/Ant or some such. On
> Windows 2K, it should
> look in \Users\username\etc...
>
> A clear mechanism for providing tasks as source code and
> compiling them
> on demand into tasks that can be used with the current project.
>
> Framework for execution in several modes -- single shot,
> repeated, and
> gui activated.
>
> Ant.app mechanics so that Ant is distributed in a way
> that makes since
> on my new favorite platform of Mac OS X.
>
> An optional servlet layer which can access build files
> and would allow
> execution of build tasks remotely. This is targeted
> squarely at setting
> up build and test farms on a multitude of environments.
>
> So -- that's my thoughts on AntEater as of right now. I do
> apologize in
> advance that I'm saying this much now, and then going to wait
> until 12/4 to
> give the full proposal. However, I'm sure that you will
> understand that I
> *don't* want to release a proposal, go away for 2 weeks, and
> then get back
> to a bunch of discussion that went nowhere because I wasn't
> there. And, I
> have to restate that I didn't think it was fair to sit on this while
> discussions continue about similar subjects on the mailing
> list. By no means
> should those discussions end. But I thought everyone should
> know my plans.
> It seems fair at least.
>
> Comments?
>
> --
> James Duncan Davidson
> [EMAIL PROTECTED]
>
> !try; do()
>
