Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 85051 invoked from network); 28 Jan 2004 18:48:38 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 28 Jan 2004 18:48:38 -0000 Received: (qmail 55598 invoked by uid 500); 28 Jan 2004 18:47:03 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 55553 invoked by uid 500); 28 Jan 2004 18:47:02 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 55483 invoked from network); 28 Jan 2004 18:47:02 -0000 Received: from unknown (HELO confixx.bestiole.ch) (66.111.0.243) by daedalus.apache.org with SMTP; 28 Jan 2004 18:47:02 -0000 Received: from apache.org (lsb-catv-6-p001.vtxnet.ch [212.147.121.1]) by confixx.bestiole.ch (8.11.6/8.11.6) with ESMTP id i0SFggP08017 for ; Wed, 28 Jan 2004 16:42:42 +0100 Date: Wed, 28 Jan 2004 16:42:51 +0100 Subject: Re: [proposal] Cleaning up our component library Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Bertrand Delacretaz To: dev@cocoon.apache.org Content-Transfer-Encoding: quoted-printable In-Reply-To: <40179466.4050201@gmx.de> Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Le Mercredi, 28 jan 2004, =E0 11:52 Europe/Zurich, Joerg Heinicke a = =E9crit=20 : > ...With our deprecated block we have another mean to lead the user to=20= > the new components. When it's excluded the application will just not=20= > work. But I don't know if this is true for 2.2 and real blocks too... hmm...I don't like the idea of moving code around to deprecate it, what=20= if a block has just one component that must be deprecated? Also, with CVS we lose code history when moving files around. Marking components with a marker interface would be less disruptive and=20= easier to undo if (when) mistakes happen. Then the component manager could trigger log messages or exceptions=20 (depending on the "strict deprecation" setting) when initializing the=20 component. > So alltogether: > > a) Components that are just renamed or replaced with only sitemap=20 > changes (FileGenerator =3D> XMLGenerator, DirectoryGenerator =3D>=20 > TraversableGenerator (or however it is called ;-) ), StreamGenerator=20= > =3D> XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in=20= > 2.2.... ok but I agree with Carsten that renaming just because names aren't=20 optimal does not make much sense. > b) Components that need "real" application changes as=20 > processPipelineTo or anything similar are also deprecated in 2.1, but=20= > will be kept in 2.2. ok > c) Deprecation messages: > Strict deprecation for a) components. 80% are catched by "file" =3D>=20= > "xml" and "file" is the default generator and "xml" will be it. > Loose deprecation with a warning on every usage (otherwise they are to=20= > easily lost in the logs) for b) components. If we also use strict=20 > deprecation here, we don't really need b). I was more thinking about a global "strict deprecation" setting,=20 defaulting to false at first, but global. Either you leave it false to=20= be able to use all components (with warnings) or you set it to true if=20= you want to make sure your app doesn't use any deprecated stuff. -Bertrand