On Mar 15, 2007, at 1:32 PM, Sébastien Geindre wrote:
Hello all !!
i wonder how your organize your source in order to have an easy
packaging and deployment of a cocoon application ?
Do you use build.sh shell command with ant generation of cocoon.war
with all your stuff inside ??
Imagine you have a webapp call 'project1' with sitemaps, xsl,
flowscript, ressources, java class ...
How do you organize it ?
Thanks.
I use Cocoon running under Tomcat on my laptop for development.
In the root sitemap is:
<!--+
| Find a match in the "mount-table.xml" file, if present. It
allows to mount other
| directories without touching this main sitemap (and thus
loosing changes on rebuild).
|
| Note that other mount-tables can be added here using the
xpatch ant task
| (see src/confpatch/mount-table.xmap)
+-->
<map:match pattern="../../mount-table.xml" type="mount-table">
<map:mount src="{src}" uri-prefix="{uri-prefix}"/>
</map:match>
From webapps/cocoon, "../.." resolved to the top level Tomcat
directory.
For me, and probably most people, Tomcat rebuilds or updates are a
lot less
frequent than Cocoon rebuilds, so once in place, that file doesn't
change much.
Cocoon and Tomcat live in my /usr/local/java directory, but the mount-
table
mounts sitemaps in my home directory. You shouldn't have to worry about
merging your app with new builds of cocoon.
If you use {contextpath:.} to pass a real path from the sitemap to
any components
that need them you should not need to hardwire any absolute paths in
your cocoon
app. ( And I sometimes have duplicate copies -- one of the
production branch of the
app and another test branch -- mounted by the mount-table. )
I don't know how the files are arranged on the production server, but
set up this
way, it doesn't matter. ( We are moving to a redundant cluster
environment, and I
don't even have login access to the production servers: I check
changes into
subversion after testing on my laptop, and post-commit scripts on the
subversion
server copy the updates to the web server. )
I was also experimenting with producing a stand-alone version on a CD-
ROM using the
standalone-demo/jetty build of cocoon. In this case, everything
relocated properly.
The only glitch:
I try to stick to relative URLs, but there are some cases where I
can't.
I've been passing a base-url to some components as:
value="http://{request:serverName}:{request:serverPort}/
{request:contextPath}"
This works, but the production server is proxied thru apache and
squid ( and I don't
know what else! ;-) and this gives URLs like:
http://real.host:8080/cocoon/my-app/...
where what I really need is something like:
http://virtual.host/my-app/...
So, for now, I've got some inconsistent hacks around this problem,
while I look for a better way of constructing the right URLs.
( And one of my inconsistent hacks is screwing up the ability to run
a test and a production version side by side -- some pages in
.../cocoon/my-test/... are linking back to .../cocoon/my-
app/... )
-- Steve Majewski / UVA Alderman Library
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
