Return-Path: <ernst@c187104187.telekabel.chello.nl>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 61042 invoked from network); 8 Jul 2000 14:15:20 -0000
Received: from c187104187.telekabel.chello.nl (qmailr@212.187.104.187)
  by locus.apache.org with SMTP; 8 Jul 2000 14:15:20 -0000
Received: (qmail 13353 invoked by uid 1000); 8 Jul 2000 14:15:11 -0000
Date: Sat, 8 Jul 2000 16:15:11 +0200
From: Ernst de Haan <ernst@jollem.com>
To: ant-dev@jakarta.apache.org
Subject: Re: Recent logging aint emacs friendly
Message-ID: <20000708161511.A13333@c187104187.telekabel.chello.nl>
References: <20000708152146.A13169@c187104187.telekabel.chello.nl>
 <002501bfe8e0$17dc11c0$80dc1fcb@cognet.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <002501bfe8e0$17dc11c0$80dc1fcb@cognet.com.au>;
 from conor@m64.com on Sat, Jul 08, 2000 at 11:26:16PM +1000

Hi Conor && all,

<snip>
> Option 1 boils downs to a single logger class which has two behaviours
> controlled by the command line parameter.
> 
> Option 2 is 2 logger classes with separate behaviours.
</snip>

I would prefer the first option, because:

   * I expect this to be `cleaner'
   * I believe it is realistic that different logging formats are
     requested in the future, like XML.

We can start by refactoring the existing code to factor the logging
stuff out and put it in a separate class. At the same time we can think
about a generic interface or abstract superclass.

Perhaps we can introduce one extra subclassing layer, so both the
emacs-friendly and the standard logger can derive from the same class
and only have to do very little to get the behaviour they require.


Ernst