cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leszek Gawron (JIRA)" <>
Subject [jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
Date Mon, 04 Sep 2006 12:19:23 GMT
    [ ] 
Leszek Gawron commented on COCOON-1898:

Concerning src/main/xpatch:

We have have agreed some time ago to keep all the specific cocoon resources in resources/META-INF
subdirectory (spring context, avalon contexts, properties, sitemap additions and now xpatch).
Why make exceptions for xpatches?

On the other side If the resulting jar file contains patches in META-INF/xpatch it really
_should_ not matter whey they are picked from in the first place. Unfortunately it does. There
is one small problem with development blocks mounted like this:


this configuration is converted later on to a mount in sitemap:
<map:match pattern="blocks/donnelley-block-common/**">
  <map:mount uri-prefix="blocks/donnelley-block-common" src="file:/c:/dev/projects/donnelley/donnelley-admin/../donnelley-block-common/src/main/resources/COB-INF/"/>

<map:match pattern="blocks/donnelley-admin/**">
  <map:mount uri-prefix="blocks/donnelley-admin" src="file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/COB-INF/"/>

The path is being built like this:
private static final String RESOURCES_DIR = "src/main/resources/";

public void setLocalPath(String localPath) throws FileNotFoundException {
    File localPathDir = new File(localPath);
    if (!localPathDir.exists()) {
        throw new FileNotFoundException("Directory '" + localPath + "' does not exist!");

    springConfPath = checkDir(new File(localPath, RESOURCES_DIR + "META-INF/spring"));
    xconfConfPath = checkDir(new File(localPath, RESOURCES_DIR + "META-INF/legacy/xconf"));
    sitemapAdditionsConfPath = checkDir(new File(localPath, RESOURCES_DIR + "META-INF/legacy/sitemap-additions"));
    xPatchPath = checkDir(new File(localPath, RESOURCES_DIR + "META-INF/xpatch"));
    targetClassesPath = checkDir(new File(localPath, "target/classes"));
    cobInfPath = checkDir(new File(localPath, RESOURCES_DIR + "COB-INF"));

Statically. If you configure something else as a resource folder - it won't be picked up by
cocoon:deploy. We probably would have to use maven API to parse appropriate pom.xml files.

We should follow both maven and cocoon conventions. Otherwise we'll have pom.xml bloated from
the start.

Concerning long command line: 
I am not maven expert and have totally no idea how to invoke create/configure/invoke a plugin
from withing another plugin. 

The run order should be: compile deploy patch shield. Patch goes before shielding before shielding
modifies web.xml. If you patched after shielding you would have to permanently choose if you
patch towards shielded/non shielded webapp.

> [PATCH] XPatch support for maven-cocoon-deployer-plugin
> -------------------------------------------------------
>                 Key: COCOON-1898
>                 URL:
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: - Build System: Maven
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Lars Trieloff
>         Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch
> The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult
to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block
should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet.
This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current
state of the deployer-plugin.
> My patch adds support for patching the web.xml file using *.xweb files in the /conf directory
of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching
the patch document temporarily and applying them (using code from the orgiginal XConfToolTask
in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb
files and does not support any property expansion.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message