Sylvain Wallez wrote:
<snip/>
Sorry to jump in late (just saw your "I commited it!" message), but what's the need for this?
I see the potential for your matcher going further than you seemed to envision.
My patch is aimed to allow the user to choose the location of the mount-table file without the need to change the root sitemap itself.
This means that the matcher can be used, without changing the root sitemap, with the webapp deployed somewhere other than in build/webapp, which is certainly my custom.
In my deployed sites, I simply add a mount right at the beginning of the root sitemap, which matches on "**", thus overriding anything else in the root sitemap (other than handle-errors, possibly).
MountTableMatchers allows externally-defined indirections to be plugged into a sitemap, and you add another level of indirection through the build property.
The indirection allows the table itself to be somewhere else, yes.
Sorry, but this really seems FS to me as I think nobody will ever change the build property, but just modify the sitemap statement...
Depends. I find it frustrating to have to re-patch the sitemap every time I rebuild Cocoon. This way, that becomes largely unnecessary.
Moreover, I don't understand the "live enviromnent" argument, as it's not desirable at all, IMO, to deploy the main samples sitemap "as is" on a live enviromnent. All the mounts it contains are either highly samples-related or automounts that are dangerous in a production environment.
I would build my Cocoon for deployment without the samples and would create my own mount table. My own mount table would, as you have already said, survive a clean build of Cocoon, so I see no problem here.
The major job here was to get the Ant task to be able to do patches using Ant properties. That is a useful feature in itself, which I think should stay.
This feature is definitely useful.
Beyond that, if you and others feel that the sitemap patch is overkill, I'm happy to remove it and just use it on my own systems (after all, that is only one file on src/confpatch).
Does this explain better what I had in mind with this? For me I see it as useful, even in a live environment, but certainly with the samples excluded.
Ok, I understand your use case, and I realize that I underestimated the unsefulness of xconftask outside of Cocoon's build environment.
So let's keep it there, and sorry for ranting :-/
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
