You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2008/08/12 14:39:58 UTC
Cocoon Maven plug-in (RCL) and custom profiles
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
Re: Cocoon Maven plug-in (RCL) and custom profiles
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> 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?
AFAIK yes
>> 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.
I'm not sure if I can follow you here. Are you talking about reusing of
profiles?
> 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.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Cocoon Maven plug-in (RCL) and custom profiles
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Re: Cocoon Maven plug-in (RCL) and custom profiles
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> 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?
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.
The code that you cited above is only a parameter value check to give
feedback if the plugin parameter is valid.
> 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
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________