tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Still playing around with Ant
Date Sun, 28 Nov 1999 15:41:41 GMT
jon * wrote:
> on 11/26/99 8:07 AM, Stefano Mazzocchi <> wrote:
> > Hi guys,
> >
> > other random comments on top of my head (sorry, but I don't have time to
> > implement them)
> oh great...make everyone else do your dirty work. ;-)

was it so evident? ;)

> > 1) the Task interface should have methods that return basic information
> > on what the task does. Something like apache modules that expose their
> > behavior as well as their configurations.
> good idea. maybe next week i will look into doing this. although, just plain
> old documentation is a MUCH higher priority imho. ;-)


Another idea is to have something like

  String getDTD()

where eash task returns a DTD fragment that Ant could use to generate a
validation schema for the build.xml file, but this is would have _way_
low priority.
> > 2) Taks is an abstract class. Following the "polymorphic" design
> > pattern, we should have
> i agree fully. Ant definitely wasn't designed with OO in mind first. ;-) As
> I said earlier, it is a great 1.0. ;-) 2.0 needs to have some better OO
> design...not just with Tasks. I guess one could say this about Apache JServ
> 1.0 as well.

Actually it's not that bad. Add just a few interfaces/abstract-class
separations, a higher level XML parser abstraction and you're pretty
much done.
> > 3) should contain a method
> >
> > setLog(PrintWriter log, boolean useXML)
> >
> > to indicate where the class should place logs and if the XML syntax
> > should be used. The task should be guaranteed this method is _always_
> > called before any execution.
> Good idea. Also, we need to have logging be consistent throughout the
> application...rightnow, it is a bad combo of project.log and
> system.out.println(). ;-(

Yes, this is why should have a common logging system, I would
also like to add something like "debug level" so that you can request
log levels syslogd-style to reduce verbosity.
> > 4) I don't like Jon's <keysubst> usage.
> biteme. ;-)

Sure, in the ass :)
> > I do consider it vital to have a
> > task that performs token substitutions, but I'd like to propose
> > something a little different. Consider something like this
> >
> > <keysubst src="" dest=""
> > setKeys="version=$(version)*name=$(name)*debug=$(debug)"/>
> >
> > it performs both a copy and a substitution, which is IMO no good.
> It kinda has to. You can't do a replacement on an existing file (in place)
> without destroying it first. Since this could be a bad thing (what if there
> was an error during the destroy process?), the best way imho, is to copy/sub
> at the same time. Note that this is how autoconf works and that is how I
> modeled it. (ie: .in files).

Sure. <replace src="" .../> has this pseudo code -(filter)->
 if (error) remove
 else remove and rename as

this is what I had in mind, which, true might follow the same pattern,
but allows you to forget about _how_ replacement is done (which is
something I don't care nor I should)

> > I would like to be able to do
> >
> > <copydir src="src" dest="$(build.src)"/>
> > <replace file="$(build.src)/" token="@version@"
> > value="$(version)"/>
> > <replace file="$(build.src)/" token="@name@" value="$(name)"/>
> > <replace file="$(build.src)/" token="@debug@"
> > value="$(debug)"/>
> > <javac srcdir="${build.src}" destdir="${build.dest}" debug="${debug}"/>
> >
> > and doing this with keysubst is much more verbose globally, even if it
> > encodes all the keys into one line.
> Yes, but that isn't how Ant works at all. The above would cause <replace> to
> be called 3 times. 

No. If you do a bunch of <copyfile> for those who don't want to be
"filtered" you do the same thing.

> On top of it, it would do the replacements on the file
> and you would be screwed (ie: loose data) if there was an error
> that prevented the new copy of to be written. Also, what if there
> is an error with the substitution?

See pseudocode above.
> Also, I don't like the idea of passing in the entire token. While it gives
> more flexibility towards what tokens get replaced, it encourages a pluthera
> of potentially bad tokens.

It's up to you to come up with the tokens you like. Why should you force
the tokens to be <token>variable<token>? what if I already have a build
system that uses "&^%$variable"? Do you really gain that much
readability by hiding/forcing the token encoding method?
> > The behavior is different, this is true, and much slower, granted, but
> > I'd like to have a task for copying the files and another for updating
> > them. keysubst is modeled out of the "sed" pattern, which is really
> > powerful, but IMO a pain in the ass to read (and to manage!) and works
> > well in pipes, that we don't have here.
> No, it isn't based on sed, it is based on how autoconf does things. While
> autoconf isn't the best thing in the world, I do like some of the design
> ideas.

> I guess my feeling is that I do like how keysubst works because it solved my
> problems. One thing I also really like about Ant is the fact that it is
> moduler. So, if you don't like it, come up with your own replacements. I'm
> not forcing you to use keysubst. ;-)

Totally true. But at least in the main distribution, I would like to
remove task functionality overlapping to remove the tons of "do I use
this or that? why do you have both?" type of questions. I'm sure you get
my point.

So, no, don't want to fight at all over this. It does the job and I love
it, but you know how picky I am... it's my "pain-in-the-ass" nature :)


View raw message