Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 34045 invoked by uid 500); 12 Dec 2001 18:29:31 -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 34032 invoked from network); 12 Dec 2001 18:29:30 -0000 Message-ID: <3C17A27F.6060601@apache.org> Date: Wed, 12 Dec 2001 13:31:27 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [WARNING] Version migrations are a headache! References: <3C179D4A.8000703@apache.org> 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 Berin Loritsch wrote: Does ANYONE remember what the value was for: Constants.SESSION_STATE_ATTRIBUTE? Or what it was replaced with? > The problem comes with changing dependencies and classnames. For > example the > SessionStateSelectorFactory has been renamed the SessionAttributeSelector. > While the second is arguably a better name, please use deprecation so that > users can be warned before the class is eliminated! > > Avalon Excalibur has a few classes which follow the following approach: > > /** > * @deprecated Use ExcaliburComponentManager instead! > */ > class DefaultComponentManager extends ExcaliburComponentManager{} > > This way the functionality is the same, but the user is pointed to the > correct version gracefully. > > It is a number of issues like this, the constant rearranging of the core > components, etc. that make moving between Cocoon versions a headache. > > I honestly think we have a few too many different types of core components, > and it would be better if they were rearranged a bit. > > This is especially true since people have portions of the cocoon.xconf > file that are specialized to their site! > > DANGER, WILL ROBINSON! > *Any* time you add a new abstract method to an abstract class, or change > an abstract method on an abstract class--that change is NOT BACKWARDS > COMPATIBLE! > > I have some specialized actions that extend > AbstractComplimentaryConfigurableAction > that are now broken because of this very thing. Now I have to figure out > what changed! > -- "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