tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Still playing around with Ant
Date Mon, 29 Nov 1999 11:41:52 GMT
James Duncan Davidson wrote:
> 
> 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.

Very nice point. Very wise practice. Don't you just love it when you
come across new design patterns :)
 
> > > 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 point. But how do you do it?
 
> > 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 :)

This is the point. I don't care either how this is done.
 
X-Mozilla-Status: 0009ry.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.

Right. <replace> should not change the original files but a copy of it.

Anyway...

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche



Mime
View raw message