[
http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432504
]
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:
<plugin>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-deployer-plugin</artifactId>
<version>1.0.0-M2-SNAPSHOT</version>
<configuration>
<useShieldingClassloader>false</useShieldingClassloader>
<useShieldingRepository>false</useShieldingRepository>
<blocks>
<developmentBlock>
<groupId>com.mobilebox.donnelley</groupId>
<artifactId>donnelley-block-common</artifactId>
<localPath>../donnelley-block-common</localPath>
</developmentBlock>
</blocks>
</configuration>
</plugin>
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>
<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/"/>
</map:match>
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: http://issues.apache.org/jira/browse/COCOON-1898
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
