Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 81726 invoked from network); 12 Aug 2008 12:41:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Aug 2008 12:41:03 -0000 Received: (qmail 93526 invoked by uid 500); 12 Aug 2008 12:40:52 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 93394 invoked by uid 500); 12 Aug 2008 12:40:51 -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 93378 invoked by uid 99); 12 Aug 2008 12:40:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2008 05:40:51 -0700 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,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.178 as permitted sender) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2008 12:39:53 +0000 Received: from [192.168.1.221] (unknown [217.116.183.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6F85023E3F6 for ; Tue, 12 Aug 2008 08:40:20 -0400 (EDT) Message-ID: <48A1849E.8080902@tuffmail.com> Date: Tue, 12 Aug 2008 14:39:58 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: Cocoon's dev mailing list Subject: Cocoon Maven plug-in (RCL) and custom profiles Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, Our Maven plug-in which handles RAD of blocks has a concept of profiles. In profile one can define default content of basic resources like web.xml or applicationContext.xml for web application prepared by RCL that will host developed block(s). The problem I have is that we have two profiles hardcoded right now: * cocoon22 * ssf The first one is rather obvious; the second one is meant for people developing on top of SSF but not using Cocoon so web.xml does not contain definitions of Cocoon-specific filters, etc. However, if you develop on top of Cocoon you still might need to customize applicationContext.xml (e.g. configuration of Spring Configurator) in order to run your block properly. Therefore, I see the need for being able to define custom profiles. Why only wonders me is this snippet[1]: // check profile if ("cocoon-22".equals(this.webappProfile)) { getLog().info("Preparing a Cocoon web application."); } else if ("ssf".equals(this.webappProfile)) { getLog().info("Preparing a Servlet-Service web application."); } else { throw new MojoExecutionException("Only the profiles 'cocoon-22' and 'ssf' are supported."); } It looks like these two profiles were intentionally hard-coded and nothing else is allowed. Is there any reason for that? If not, wouldn't anybody mind if I implemented the ability to define custom profile and provide it as dependency for Cocoon Maven plug-in? [1] http://svn.eu.apache.org/viewvc/cocoon/trunk/tools/cocoon-maven-plugin/src/main/java/org/apache/cocoon/maven/rcl/PrepareWebappMojo.java?view=markup -- Best regards, Grzegorz Kossakowski