At 07:34 8/5/01 -0700, Jon Stevens wrote: >on 5/8/01 7:24 PM, "Peter Donald" <[EMAIL PROTECTED]> 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. > >Huh? > >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 application. 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 them. >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. Cheers, Pete *-----------------------------------------------------* | "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 | *-----------------------------------------------------*
