Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 81269 invoked from network); 13 Dec 2006 10:40:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Dec 2006 10:40:34 -0000 Received: (qmail 2850 invoked by uid 500); 13 Dec 2006 10:40:39 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 2821 invoked by uid 500); 13 Dec 2006 10:40:39 -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 2805 invoked by uid 99); 13 Dec 2006 10:40:39 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2006 02:40:39 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [213.46.255.18] (HELO viefep20-int.chello.at) (213.46.255.18) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2006 02:40:04 -0800 Received: from [192.168.1.30] (really [62.178.239.20]) by viefep20-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20061213103934.KGSK18937.viefep20-int.chello.at@[192.168.1.30]> for ; Wed, 13 Dec 2006 11:39:34 +0100 Message-ID: <457FD863.40105@apache.org> Date: Wed, 13 Dec 2006 11:39:31 +0100 From: Reinhard Poetz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others) References: <4572BAF3.4050001@apache.org> <457D6E4C.30306@apache.org> <457E81A0.4030507@otego.com> <457E8C91.6090305@apache.org> <457F4A18.7080100@apache.org> In-Reply-To: <457F4A18.7080100@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Simone Gianni wrote: > Reinhard Poetz wrote: >> Giacomo Pati wrote: >> >>> One little fix I have encountered yesterday and fixed it this >>> morning. The deployer-plugin was not >>> applying xpatches in case of war (I thought >>> this was not intended, right?). >> The deployer plugin hasn't been released this time. I want to work on >> a second part of release artifacts (deployer, forms, apples, mail) >> before Xmas, but can't promise it. >> > Hi Reinhard, > maybe I can help with the deployer plugin. What should it do now with > the current structure? I manage to build 2.2 WARs with my blocks inside > without the need of the deployer. IIUC it is still needed when reloading > classloader comes in play, but for doing what? no, the reloading classloader plugin I'm working on is completly independant from the deployer plugin. The deployer plugin only has two features that we really need: - patching web.xml (*.xweb) - provding a minimal environment to run a block (has been merged into the reloading classloader plugin and will become absolete as soon as we can release it - we have to wait until commons-jci provides a release which won't happen before January) I think we should release the deployer plugin as it is and after that we should clean it up and remove everything except the web.xml patching feature. As, IIRC, Carsten proposed some time ago, this could be also proposed as patch for the maven-war plugin. As always, the question his if somebody cares about it. -- Reinhard P�tz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc --------------------------------------------------------------------