ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [Vote] Logging
Date Wed, 09 May 2001 03:04:49 GMT
At 07:34  8/5/01 -0700, Jon Stevens wrote:
>on 5/8/01 7:24 PM, "Peter Donald" <> wrote:
>> like you did with turbine? Where those interfaces/classes are larger, more
>> complex and harder to maintain than an existing toolkit. Kind of defeats
>> the whole purpose of having a logging toolkit maintained outside the
>> project don't you think?
>What are you talking about? Neither Turbine's or Velocity's implementations
>are complex or hard to maintain, nor do they add any overhead to the system.

turbine has more lines of code than logkits core, is a custom system, has
not had anywhere near the same level of testing as either log4j or logkit.
You just reinvent a new logging toolkit inside turbine - sounds smart.

>In fact, they are quite simple. The only time they are hard to maintain is
>when *YOU* go and change the interfaces and break things. Yes people, this
>has happened just recently.

yer - 1 time in close to two years it changed in a backward incompatible
and I patched velocity for you. If you notice 

>In fact, one could argue that Log4J cares about backwards compatibility and
>your LogKit doesn't and that we should use Log4J because at least I know
>that it will work into the future and that Ceki understands the need for
>deprecation. Something you have yet to show me.

grow up. Log4j has always been a moving target until recently with it's 1.x
release. LogKit has only once broken backwards compatibility - both have
been around for around 1.5-2 years? So you do the figures -- ooh guess
which one comes in as more stable?

>> why add complexity to ant when it is not needed?
>It is needed because clearly some people want to use Log4J and others (ie:
>you) want LogKit.

so - people want to add if/while to ant, people want to incroporate return
values from targets, people want to do all sorts of things. Luckily 

>> People build toolkits to be reused - could you imagine everytime you wanted
>> use JDOM you had to create a wrapper around it - and make it generic enough
>> that it fit other similar toolkits. Stupid - yes I would have to agree.
>What the heck do you think JAXP (or the proposed Logging API) is for?

It has nothing to do with JDOM ;)

>People like the ability to swap out their XML parser 

because some ofthem have different implementation strategies - something
which is not the case with logging.

>(and logging implementation) at will without needing to re-write their

yer - right. Yet to see that. People like to swap things in and out when
there is different implementation strategies or a generic way of specifying
features. Logging toolkits are unlikely to have either - they merrily have
pluggable backends (appenders/logtargets/formatters/whatever).

Question - why doesn't the JDK have pluggable HashMaps - your positions
would indicate that they should - and that they should have wrapper
interfaces to interact with them.

Same goes for ClassLoaders - why doesn't the JDK allow pluggable
classloaders - your logic dictates that they should cause some could want

>So, my vote is that I'm strongly -1 on binding Ant to any specific logging
>implementation, especially LogKit.

So again - what advantage do you see in duplicating the work in ant that
exists in other projects?

Remember - "because we can" is not a valid answer.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message