tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: Still playing around with Ant
Date Sun, 28 Nov 1999 23:50:18 GMT
jon * wrote:
> > 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. ;-)

Yep. Documentation is a big item to address asap.

> > 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 I left it as an abstract class on purpose. The reason why is
that I wasn't settled on exactly how the signatures should be and it's
much easier to maintain compatibility with subtypes if you are modifying
an Abstract Class rather than an Interface. Once you distribute an
interface that people might rely upon outside of your code base, you
really shouldn't ever tweak it again as to do so creates nasty
versioning problems. Once it's happy, then the interface can be
promoted.

> > 3) Task.java 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.

I don't like the task knowing that the logging should be in XML terms.
The task should be able to write without caring and the end result log
is xml'ized.

> 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(). ;-(

Also, I don't see a substantial difference between calling

	project.log("foo");
	
	and

	task.setLog(log);
	log.write("foo");

I agree that all the System.out.printlns need to go though :)

> > <keysubst src="try.java" dest="try.new.java"
> > 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).

I like jon's process as well as my preference is to leave files in the
workspace "pristine" except for edits. And, given that you've got to
copy the file over, it's a good time to do the substitutions.

.duncan

-- 
James Davidson                                     duncan@eng.sun.com 
Java + XML / Portable Code + Portable Data                 !try; do()



Mime
View raw message