Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 17720 invoked by uid 500); 4 Dec 2002 16:01:43 -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 17707 invoked from network); 4 Dec 2002 16:01:43 -0000 Message-ID: <1039017703.3dee26e7a7963@imp.dff.local> Date: Wed, 4 Dec 2002 17:01:43 +0100 From: tcurdt@dff.st To: cocoon-dev@xml.apache.org Subject: Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module ) References: <3DEE1F05.8000406@apache.org> In-Reply-To: <3DEE1F05.8000406@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 172.16.2.8 Sender: www-data X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Quoting Nicola Ken Barozzi : > Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm > making this into a proposal. > > _Proposal_ > > This proposal is to create a source section parallel to blocks, to hold > Cocoon "parts", or "modules", that are not part of the Cocoon minimal > core but need nevertheless to be included in the classpath and config > files at startup. > > They would look identical to the current "blocks", ie jars. The > difference is that they will never be hot-pluggable as Cocoon > Components, and are not part of the Block concept. > Thus, when proper .cob blocks will arrive, the /blocks will migrate to > that packaging format, while these "modules" will not. > > Possible candidates to be repackaged as modules: > 1 - deprecated classes that are not Cocoon Components > 2 - Environment implememtations > 3 - "frontends" like CocoonServlet.java and Main.java > 4 - samples > 5 - module implementations > 6 - profiler Hm... this could really make it hard to have an overview of the codebase. Consider you are looking for a specific class... It might be in module A java/org/apache/cocoon/... or in module B java/org/... For some classes it *might* not be obvious in which module to find them... BTW: I bet people will getting cross-eyed having to deal with modules as well as with blocks. ("What's the difference?" gonna be a candidate for the FAQ) ...so I am currently -0.25 :-/ -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org