On Saturday 05 June 2004 05:31, Jörg Hohwiller wrote: > seems that this list is more interested on philosophy about spam and the > universe than disscussions about the philosophy of avalon - nice jokes > about that spam anyways but I would like to see some response to my mail or > is it misplaced here???
Not at all... Somehow, I have missed your mail, possibly due to it was sent in the middle of the transition from CVS to Subversion.... Also, postings that are very 'neutral' have a tendency of not getting responses, i.e. "ok, I read it, but nothing much to add or dispute..." Anyway... > On Friday 21 May 2004 17:12, Jörg Hohwiller wrote: > > I can see there is commons-configuration (which seems as it came from > > avalon) and commons-logging. I saw in the archive that there was a > > discussion about logkit vs. commons-logging + log4j before. > > I would like to know if you are planning to directly use c-configuration > > and c-logging in the avalon framework API? As for Merlin, the answer to this is "No, we are not.". In logging, I think we need a more powerful classloading mechanism than commons-logging can support, but I am not sure whether we can provide a plugin for commons-logging in Avalon Logging, but that seems to be "cake on cake". I am not well versed in commons-configuration, and don't have any comments on why. It just hasn't been discussed. > > I personally think the commons initiative is a great thing and I can > > still remember myself digging deep in apache projects sources to find a > > ready to use cache, pool or whatever implementation. > > Now why not just using these APIs as part of the avalon API? > > I can see that changing an API this way in general is a bad thing because > > of loosing downward compatibility but on the other hand it is not a bid > > thing to replace org.apache.avalon.framework.configuration to > > org.apache.commons.configuration and org.apache.avalon.framework.logger > > to org.apache.commons.logging (okay the last one is not just a string > > replace). Well, being a framework, we have a fair amount of compatibility concerns, and replacements are out of the questions. Either a compatibility wrapper is provided or both are supported, and the component implementor makes a choice. > > So all I am suggesting is think about it. > > Disscussions welcome... Change for the sake of change is not something I would typically spend my time on, and if no arguments are put forward of WHY a change should be done, I am sure it won't happen. What does the change bring to us (except increased maintenance)? Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
