[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ https://issues.apache.org/jira/browse/COCOON-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570496#action_12570496 ] Olivier Billard commented on COCOON-1898: - Hi there, This issue is quite old, and I also have the need of patching cocoon.xconf file in a mavenized Cocoon 2.1.x application. I have several jar artefacts corresponding to different possible configurations (a base core, and customers-oriented/specific functionalities). Is there any chance this would be managed ? Thanks ! [PATCH] XPatch support for maven-cocoon-deployer-plugin --- Key: COCOON-1898 URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432499 ] Lars Trieloff commented on COCOON-1898: --- Leszek, there are some weak points in the XUpdate language, for example the if-semantics are not yet defined. Putting the patches below src/main/xpath is no problem when you add this path to the list of paths that are considered by the jar plugin (or whatever does the packaging) I understand your motivation for multiple patches targeting one file. For the long command line: could not the cocoon-deployer call cocoon:xupdate before finishing the deployment? The deployer scans the required jar files for patches, extracts them to a target/xpatch directory, calls cocoon:xupdate which then uses patches in target/xpatch and /src/main/xpatch to patch the extracted files. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[
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
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-deployer-plugin/artifactId
version1.0.0-M2-SNAPSHOT/version
configuration
useShieldingClassloaderfalse/useShieldingClassloader
useShieldingRepositoryfalse/useShieldingRepository
blocks
developmentBlock
groupIdcom.mobilebox.donnelley/groupId
artifactIddonnelley-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:
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432339 ] Simone Gianni commented on COCOON-1898: --- Sorry to jump on this issue so late, but I also was in the need for a patching mechanism for web.xml and other files, and came up with another solution, mainly because i don't like XPatch that much (had to fight with it a lot in the past). I aldready developed and I'm using internally the mvn plugin for it, it works using a src/main/xpatch folder, containing the patch files, so for example to patch the web xml you create a file src/main/xpatch/WEB-INF/web.xml-adding-filter.xml. My xml patching syntax is by far simpler than xpatch, for example to add a filter in the web.xml you just have to write a file like this : web-app xmlns:xp=http://xpatch/1.0; filter/ !-- With this you are telling it to find the first filter/ entry -- filter xp:do=add !-- With this you are telling it to add this node and its children -- filter-nameMyFilter/filter-name display-nameMy filter/display-name filter-class/filter-class init-param param-nameparam/param-name param-valuevalue/param-value /init-param /filter filter-mapping/ filter-mapping xp:do=add filter-nameMyFilter/filter-name servlet-nameCocoon/servlet-name /filter-mapping /web-app For many other tasks it's even simpler, for example to add a new match on the root sitemap, this is enought : map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0; map:pipelines map:pipeline map:match pattern=_mystuff/** map:mount src=mystuff/ uri-prefix=_mystuff/ /map:match /map:pipeline /map:pipelines /map:sitemap and the new match will be added as the last element of the first encountered pipeline. I'm planning to contribute this anyway, so let me know if it could be a good alternative. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432356 ] Leszek Gawron commented on COCOON-1898: --- To tell you the truth I like XPatch syntax better than your solution. You can understand what the xpatch does even if you never seen the syntax before. Your format has to be well described, otherwise it does not look like a patch file at all. XPatch is more similar to a xsl stylesheet, which is good. XPatch due to it's full XPath (no 'c' before 'h' :)) ) support is way more powerful. What is it that you dislike in XPatch. Maybe we could fix it. I want to implement some more features for cocoon:deploy XPatching: 1. the ability to patch any xml file in cocoon webapp by putting the patch file into /src/main/resources/META-INF/xpatch/blocks/myblock/sitemap.xmap.patch.001.description or /src/main/resources/META-INF/xpatch/WEB-INF/cocoon/cocoon.xconf.001.description-here I figured you have the same path resolution in your solution. 2. xpatch sorting: /src/main/resources/META-INF/xpatch/WEB-INF/cocoon/cocoon.xconf.001.description-here /src/main/resources/META-INF/xpatch/WEB-INF/cocoon/cocoon.xconf.002.other-patch-here this way you may control what patch gets applied first 3. xpatching for both development mode and full cocoon webapp 4. xpatch profiles you will be able to apply only some patches depending on what profile you want enabled (dev,prod,test). This may conflict a little bit with 1). [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432367 ] Lars Trieloff commented on COCOON-1898: --- I like the idea of being able to patch any XML file in cocoon, but I would not place them in src/main/resources, but to src/main/xpatch/, just to reduce the cluttering of the src/main/resources directory. Having multiple patch files targeting one file sounds like no good idea when you can have multiple patch targets in one patch file. This should also be the place where profile conditions should be enabled (ideally through property replacement as done in the original ant tasks.) The most important argument for chosing XPatch over any other format (e.g. the more widely distributed standard XUpdate) is that it is already in use in Cocoon. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432369 ] Leszek Gawron commented on COCOON-1898: --- putting your xpatch files into /src/main/resources/META-INF/xpatch allows to pack them into the artifact (jar). This way the patch file can be applied anywhere later just by declaring a dependency in pom.xml. Example: myapp-block-core defines a set of application services along with transaction management. It also provides a patch file that enables OpenSessionInViewFilter for hibernate: ?xml version=1.0? xweb xpath=/web-app unless=comment()[contains(., 'Spring filters')] insert-before=servlet !-- Spring filters -- filter filter-nameopenSessionInViewFilter/filter-name filter-class org.springframework.orm.hibernate3.support.OpenSessionInViewFilter /filter-class /filter filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/*/url-pattern /filter-mapping /xweb the application also has an administration interface: myapp-block-admin-interface. It is sufficient to declare a dependency on myapp-block-core in myapp-block-admin-interface's pom.xml file and you will be able to do: myapp-block-admin-interface mvn clean compile cocoon:deploy jetty:run having access to all core's services and OpenSessionInViewFilter properly declared in web.xml. If you have a single block that uses core your proposal would be fine. You could put the xpatch file locally to myapp-block-admin-interface/src/main/xpatch and get it applied while testing administration interface. But imagine your application consists of 20 blocks every depending on core. Every block would have to keep it's own copy of xpatch file to have core working properly. ugly :) It is nothing unusual that several patches target one file. Extending my example: myapp-block-core provides transaction management and provides a patch for OpenSessionInViewFilter myapp-block-security provides acegisecurity services that need 2 patches in web.xml: filter filter-nameAcegi Filter Chain Proxy/filter-name filter-classorg.acegisecurity.util.FilterToBeanProxy/filter-class init-param param-nametargetClass/param-name param-valueorg.acegisecurity.util.FilterChainProxy/param-value /init-param /filter filter-mapping filter-nameAcegi Filter Chain Proxy/filter-name url-pattern/*/url-pattern /filter-mapping and listener listener-classorg.acegisecurity.ui.session.HttpSessionEventPublisher/listener-class /listener My 2.1.x production sites also have 3-7 patches targeting cocoon.xconf. As long as they did not impose ordering constraints I prefered to keep them in several files and reuse in different projects. In few rare cases you need to insert data in a specified order (like servlet filters). Then the xpatch ordering I was describing comes into play. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432371 ] Leszek Gawron commented on COCOON-1898: --- Lars, I've been looking into XUpdate and it is promising. I had no idea this kind of language was already implemented. I think it is some solution between current XPatch and Simone's proposal. Simone, would you care to look into also? http://www.xmldatabases.org/projects/XUpdate-UseCases/ http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html What I like about it the most is the fact that it's externally documented :) Most useful things I learned in cocoon last weeks I got from browsing a source code because the documentation was simply inexistent. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432375 ] Leszek Gawron commented on COCOON-1898: --- This would probably be a good idea if cocoon:deploy had no xpatching abilities. A separate XPatch/XUpdate plugin could be fired. The only thing I really dislike is the probable command line: mvn clean war:exploded cocoon:deploy cocoon:xupdate jetty:run -o -Dmaven.test.skip=true couldn't we make it any shorter. Isn't there any way to have only: mvn clean cocoon:build jetty:run? I do not want to have cocoon war'ed or installed into local repository also. That means copying lots of MBytes on my slow laptop's drive. Please advise. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432142 ] Leszek Gawron commented on COCOON-1898: --- I have commited some initial version of xpatch support. There are some bugs and enhancements pending so I am not closing the issue now. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12431829 ] Leszek Gawron commented on COCOON-1898: --- Main sitemap. Not always a block can be tested in total isolation. Just as the block may require some servlet filters (e.g. hibernate3.OpenSessionInViewFilter) it also might need some additional sitemap entries (e.g. mounting external resources). I do not like the fact that in current patch the directory is located in module-dir/conf. I'd like the patch files to be put under src/main/resources/META-INF/xpatch. This way they go into the artifact jar and then the following scenario is possible: Every block (say myapp-block-admin-interface, myapp-block-client-interface) needs transactions. I define a myapp-block-core block that has an appropriate applicationContext.xml (dataSource, transactionManager and such) and xpatch file that defines a servlet filter (hibernate3.OpenSessionInViewFilter). Simply declaring a dependency on myapp-block-core in myapp-block-admin-interface is sufficient to have my web.xml patched for local development. When a project has a significant number of modules it is way more convenient for the core block to bring xpatch along with itself rather than define a xpatch file for each module that needs it. We could apply the same logic for xpath files as for settings: profiles. Some xpatch files will be no matter what. Some will be only applied in development mode. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12431830 ] Leszek Gawron commented on COCOON-1898: --- Writing main sitemap I meant the one that is generated by cocoon:deploy automatically thus the user has no control over it. [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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12431967 ] Leszek Gawron commented on COCOON-1898: --- The patch needs some polishing. Working on it now. [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
