Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 16687 invoked from network); 11 Aug 2007 10:50:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Aug 2007 10:50:59 -0000 Received: (qmail 99259 invoked by uid 500); 11 Aug 2007 10:50:56 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 99154 invoked by uid 500); 11 Aug 2007 10:50:56 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 99140 invoked by uid 99); 11 Aug 2007 10:50:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Aug 2007 03:50:56 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates 216.86.168.179 as permitted sender) Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Aug 2007 10:50:51 +0000 Received: from [192.168.0.129] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id 62416A328F for ; Sat, 11 Aug 2007 06:50:26 -0400 (EDT) Message-ID: <46BD945D.9090801@tuffmail.com> Date: Sat, 11 Aug 2007 12:50:05 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Cocoon's dev mailing list Subject: Introduction of cocoon-container core module Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hello, I'm playing with COCOON-2110 at the moment and run into problem with writing test for new functionality. Our current code is messed a little when it comes to modules affilation. For example, our Avalon-Spring bridge[1] code is in cocoon-sitemap-impl module. Tests[2] for functionality (PreparedVariableResolver class) belonging to cocoon-sitemap are in cocoon-core. This two examples are the most prominent but there are some more. I'm especially interested in PreparedVariableResolverTestCase because I want to write tests for my code handling new expression evaluation. I need dependency on cocoon-expression-language-impl in cocoon-core, of course. The problem is that cocoon-expression-language-impl already depends on cocoon-core because it makes use of o.a.c.CocoonTestCase defined in core. This introduces an cyclic dependency. Similar situation occurs when I want to move PreparedVariableResolverTestCase to the cocoon-sitemap-impl module. Having said that I would like to propose introduction of new core module 'cocoon-container' where I would move our Avalon-Spring bridge, base TestCases and other related stuff. This way we should have cleaner dependencies and more freedom when it comes to moving stuff. I've already played with such approach locally and as for now it seems to work well. Thoughts? Objections? PS. I'll start to commit this stuff really soon because I need it know. If someone objects and give other solution I'll be fine to revert my work. [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/ [2] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/components/treeprocessor/variables/ -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/