Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 1422 invoked from network); 5 Sep 2006 07:28:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Sep 2006 07:28:01 -0000 Received: (qmail 87843 invoked by uid 500); 5 Sep 2006 07:27:58 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 87767 invoked by uid 500); 5 Sep 2006 07:27:58 -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 87756 invoked by uid 99); 5 Sep 2006 07:27:58 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Sep 2006 00:27:58 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [212.85.125.162] (HELO v07528.home.net.pl) (212.85.125.162) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 05 Sep 2006 00:27:57 -0700 Received: from sj163.internetdsl.tpnet.pl (HELO ?192.168.1.62?) (lgawron.mobilebox@home@80.55.87.163) by m029.home.net.pl with SMTP; Tue, 5 Sep 2006 07:27:35 -0000 Message-ID: <44FD26EF.60609@mobilebox.pl> Date: Tue, 05 Sep 2006 09:27:43 +0200 From: Leszek Gawron User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: XPatch support for maven-cocoon-deployer-plugin References: <21942583.1157302163322.JavaMail.jira@brutus> <44FB15DB.3010205@apache.org> <44FB182F.5010802@mobilebox.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Giacomo Pati wrote: > I'm not sure what this xpatch stuff is all about (I thought we've been > over it with patching in 2.2). But what about > > src/test/webapp/WEB-INF/web.xml > src/test/webapp/sitemap.xmap We've been discussing a variation of this approach here [1]. My point was: there is myblock-opensessioninview-enabler. It has a patch to web.xml: openSessionInViewFilter org.springframework.orm.hibernate3.support.OpenSessionInViewFilter openSessionInViewFilter /* If the patch is carried along with the myblock-opensessioninview-enabler block any other block (say myblock-client-interface) is able to have web.xml patched just by stating dependency on myblock-opensessioninview-enabler. There are already some blocks in cocoon that are used alike: cocoon-trunk\blocks\cocoon-databases\cocoon-databases-oracle-client cocoon-trunk\blocks\cocoon-databases\cocoon-databases-postgresql-client The only thing the block does is ensuring the proper class gets loaded. > src/test/webapp/WEB-INF/web.xml > src/test/webapp/sitemap.xmap Those are not the only files that need patching right now. > > if you need special ones for testing your block (packaging=jar)? > > For packaging=webapp you don't really need patching at all as you are in > total control of it! Same goes for webapp. Even if I have a total control over webapp I want this definition to look exactly the same in all projects in my company. This way I make my myapp-webapp depend on myblock-opensessioninview-enabler and thats it. [1] http://issues.apache.org/jira/browse/COCOON-1898 -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65