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/04/27 20:58:43 UTC
Re: svn commit: r651728 - /cocoon/trunk/tools/cocoon-maven-plugin/src/main/resources/org/apache/cocoon/maven/rcl/profiles/cocoon-22/WEB-INF/web.xml
gkossakowski@apache.org pisze:
> Author: gkossakowski
> Date: Fri Apr 25 15:40:48 2008
> New Revision: 651728
>
> URL: http://svn.apache.org/viewvc?rev=651728&view=rev
> Log:
> RCL must take into account newly created BlockDeploymentServletContextListener.
>
[...]
> <listener>
> + <listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
> + </listener>
> + <listener>
> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
> </listener>
> <listener>
At the time of committing this fix I forgot about our xpath functionality for web.xml. Now I wonder
what's better solution, to add this to RCL profile or just let cocoon-blockdeployer to provide XPath
file for web.xml?
Reinhard, could you comment?
--
Grzegorz Kossakowski
Re: Cocoon Maven plugin: How to automatically use if for war
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Pötz wrote
>
> Maybe somebody can work out a solution that finds a better way to
> integrate the cocoon:deploy goal. Actually it is a very small wrapper
> around the Maven WAR plugin that adds xpatch and the shielding
> classloader (not to be confused with the reloading classloader).
> Is there a possibility to set the Cocoon Maven plugin as the plugin that
> creates the artifact for <packaging>war</packaging> modules instead of
> the Maven WAR plugin which is the default?
I don't know how to do it, but I think someone told me at ApacheCon in
Atlanta
(perhaps Ralph or Brett) that this is possible.
I tried to convince Ralph that at least the shielding stuff is of
general interest and to add it to the maven war plugin (I submitted a
patch years ago), but so far I did not succeed...
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Cocoon Maven plugin: How to automatically use if for war
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> gkossakowski@apache.org pisze:
>> Author: gkossakowski
>> Date: Fri Apr 25 15:40:48 2008
>> New Revision: 651728
>>
>> URL: http://svn.apache.org/viewvc?rev=651728&view=rev
>> Log:
>> RCL must take into account newly created
>> BlockDeploymentServletContextListener.
>>
> [...]
>> <listener>
>> +
>> <listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
>>
>> + </listener>
>> + <listener>
>>
>> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
>>
>> </listener>
>> <listener>
>
> At the time of committing this fix I forgot about our xpath
> functionality for web.xml. Now I wonder what's better solution, to add
> this to RCL profile or just let cocoon-blockdeployer to provide XPath
> file for web.xml?
I'm in favor of adding a "targetVersion" property to the Cocoon Maven
plugin configuration. I think we are going to need this because
otherwise you couldn't use the latest plugin with older versions of the
Cocoon subproject modules.
Given, the use of the xpatch mechanism would solve at least this problem
with automatic upgrades of your web.xml, but this would force everybody
to use cocoon:deploy and cocoon:deploy-war to create deployable .war
artifacts. The downside of this approach is that it's not fully
integrated into the Maven build life cycle and you can't do 'mvn
release:prepare release:perform' or 'mvn deploy' anymore for them. Hence
I don't think it's a good idea to force everybody to use 'mvn
cocoon:deploy'.
Maybe somebody can work out a solution that finds a better way to
integrate the cocoon:deploy goal. Actually it is a very small wrapper
around the Maven WAR plugin that adds xpatch and the shielding
classloader (not to be confused with the reloading classloader).
Is there a possibility to set the Cocoon Maven plugin as the plugin that
creates the artifact for <packaging>war</packaging> modules instead of
the Maven WAR plugin which is the default?
--
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, PMC Chair reinhard@apache.org
________________________________________________________________________