ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Configure->Template->Build
Date Mon, 28 May 2001 14:56:14 GMT
> From: Peter Donald []
> ....
> then have a shot and prototyping a few different ways of
> separating out the
> Configure->Template->Build stages in builds. I was thinking
> about using
> XSLT for template stage (as I know that) and wonder what you
> think would be
> best for Configure stage.
> Ways of doing Configure include;
> 1. tricky target manipulation combined with
> available+condition style tasks
> (ie what would be done in ant1 minus "doing" work).
> 2. (1) combined with addition of evil if/then/case/foreach tasks
> 3. Use some preexisting scripting language to test and set
> properties -
> possibly combined with parts of (1).
> I favour 3 atm and was thinking of using either jython or rhino as
> scripting base (mainly as I know both of them). Anyone have any better
> ideas ???

I got to say, I am very -1 on going the way of make and getting on the
bussiness of an autoConfig sort of way of solving problems. I do not see the
need for that.

Templates are a different matter, but I see them more as a mechanism for
users to define preferences for tasks and for them to define their own high
level tasks as composition of ANT's low level tasks.

I see the ability to write cryptic files that are only 3 lines long and from
that produce a 50 pages long ANT file, to be king of outside ANTs goals.

Now providing a hook or something for those who really want to go that way,
well I may be convinced of that, but as such we shouldn't be in the
bussiness of deciding what technologies they should or they should not use.
They should be on their own on that.

The mechanism should be similar to that of the listeners. The hook should
implement some  interface, in which we pass the input stream of the
buildfile and and a the SAX ContentHandler needed by project helper. It is
upto the user class to produce a stream of SAX events corresponding to the
ANT pseudo DTD. We may give access also to the list of args in main so the
tool can access its own additional options. That should be all.

	public interface AntPreprocessor
	  void preProcess(InputStream inbuild, String[] options, ContentHandler

	  // This second one is to be able to compose preprocessors
	  ContentHandler getProcessor(String[] options, ContentHandler out);

The idea with the second one is that you can use it for chaining them.
Notice that the first does not even require for the input to be XML, it just
needs to generate SAX events at the end of the day.

Well, enough rambling ....

Jose Alberto

View raw message