Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 52377 invoked by uid 500); 27 Sep 2002 19:59:07 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 52365 invoked from network); 27 Sep 2002 19:59:07 -0000 Message-ID: <3D94BA17.4000603@apache.org> Date: Fri, 27 Sep 2002 16:05:43 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Getting rid of deprecated Interfaces/Classes/Methods References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Giacomo Pati wrote: > Ok, this thread had made alot of people think about it and the conclusion > is that we should not switch to a newer/better container at least until a > 2.1 release is out, right? > > I've allready commited the step 1 (Loggable -> LogEnabled). > > Now I'm on step 2 (as there has not been any -1). This can be done while > we stay with ECM for now and have still backward compatability for all > custom Components somebody has around for his private projects. > > But I have some questions about this move. We have classes named after > the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd > like to hear your suggestion how we should deal with those: > > 1. don't change the names > 2. rename them to appropriate names like CocoonServiceManager > 3. create new one and deprecate the old ones > > What is your oppinion? The CocoonComponentManager et. al. are internal classes that are used in the core. They can be altered safely without breaking client code. The ComposerAction OTOH is something that a client may have extended to write their own Actions. In that case you *have* to do the deprecation and new version. My suggestion is to determine whether the class is really meant to be used by users of Cocoon. That would include the abstract classes to implement new pipeline components. If it is an internal component, then you can easily change it without repurcussion. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org