From dev-return-89381-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Mon Sep 04 07:45:05 2006 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 45339 invoked from network); 4 Sep 2006 07:45:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Sep 2006 07:45:03 -0000 Received: (qmail 36186 invoked by uid 500); 4 Sep 2006 07:45:01 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 36114 invoked by uid 500); 4 Sep 2006 07:45:01 -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 36103 invoked by uid 99); 4 Sep 2006 07:45:01 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO [127.0.0.1]) (209.237.227.194) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Sep 2006 00:45:00 -0700 Message-ID: <44FBD9F3.1070503@apache.org> Date: Mon, 04 Sep 2006 09:46:59 +0200 From: Carsten Ziegeler 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> <44FB202B.4040705@mobilebox.pl> In-Reply-To: <44FB202B.4040705@mobilebox.pl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 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 Leszek Gawron wrote: > Just a few examples of what can be currently achieved only by patching: > > - tweaking store janitor > > - configuring transient store max objects > > - configuring continuations manager > These three things could be configured through properties I guess. So there shouldn't be a need for patching. > - you won't even be able to define a new cforms widget definition > because they don't use the new service selector that allows to span > components over several files. > > While some things are trivial to fix some are not and all definitely > need some committer attention. The problem with declaring widgets in > other files is probably a year old. > Yes, I think cforms in general is the hardest bit: it's not possible for exampe to add a converter to a datatype without patching. We should definitly come up with a better configuration which does not require any patching just for adding new widgets, converters etc. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/