Return-Path: 
 <dev-return-100405-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 46562 invoked from network); 25 Aug 2008 15:09:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 25 Aug 2008 15:09:06 -0000
Received: (qmail 79819 invoked by uid 500); 25 Aug 2008 15:09:04 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 79427 invoked by uid 500); 25 Aug 2008 15:09:04 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 79410 invoked by uid 99); 25 Aug 2008 15:09:04 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Aug 2008 08:09:03 -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; Mon, 25 Aug 2008 15:08:05 +0000
Received: from [192.168.1.235] (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 E321D23E4AF
	for <dev@cocoon.apache.org>; Mon, 25 Aug 2008 11:08:34 -0400 (EDT)
Message-ID: <48B2CAD6.6060000@tuffmail.com>
Date: Mon, 25 Aug 2008 17:08:06 +0200
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20071114)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Cocoon Maven plug-in (RCL) and custom profiles
References: <48A1849E.8080902@tuffmail.com> <48A18AF2.70404@apache.org>
In-Reply-To: <48A18AF2.70404@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org

Reinhard P�tz pisze:
> There hasn't been any alternative useful value so far. Actually it isn't 
> done by just setting a profile parameter. The content also needs to be 
> somewhere available.

Actually now content is read from classpath, right? I think it should stay the same for any other 
custom profiles.

My idea is that it's an artifact that stores profile resources and Cocoon Maven plug-in simply 
depends on it. The configuration would look like:

       <plugin>
         <groupId>org.apache.cocoon</groupId>
         <artifactId>cocoon-maven-plugin</artifactId>
         <version>1.0.0-M3</version>
         <dependencies>
           <dependency>
             <groupId>org.custom</groupId>
             <artifactId>custom-profile</artifactId>
             <version>1.0.0</version>
           </dependency>
         </dependencies>
       </plugin>

Then, if I'm correct, Maven would attach this artifact to the classpath when executing Cocoon Maven 
plug-in so existing code reading profile resource would remain the same, right?

> The code that you cited above is only a parameter value check to give 
> feedback if the plugin parameter is valid.

That's true.

>> 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?
> 
> Custom profiles are already supported but I admit that the naming is not 
> consistent. You can use the customWebappDirectory configuration 
> parameter and point to a directory that contains your custom webapp 
> files. See 
> http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/prepare-mojo.html#customWebappDirectory 

Thanks for pointing me to this setting. It turned out to be useful but there is one problem with 
this approach. The directory containing webapp resources is just simple directory in filesystem 
which would be in most cases placed outside the project that depends on it. The problem is that then 
this directory is not versioned from project's point of view. When you point project to custom 
webapp directory you pass no information about a version that you are interested in.

That's why I think that packaging this custom profile as a Maven artifact which is versioned and can 
be referenced form whatever project needs it makes more sense.

WDYT?

-- 
Grzegorz Kossakowski