So I wrote in 2.2 an experimental per-sitemap classpath that allows each sitemap to define its own specific classpath for the components defined by <map:components>.
The syntax is as follows (the sitemap is in src/webapp hence the "../.."). <map:components> <map:classpath> <class-dir src="../../build/eclipse"/> <lib-dir src="../../lib"/> </map:classpath> <!-- other components --> </map:components>
Hmmm, I've used this for the first time today and I have to say that I would love my cocoon application to be 'self-contained', so to speak, so that I can move it around at best.
What I've done is:
1) package my stuff so that it looks like a real block
README.txt
INSTALL.txt
sitemap.xmap <-- this is my block sitemap
stylesheets <-- this is the block resources
* <-- add other resources at will
src/java <-- this is the components sources
lib <-- this contains the jar my code depends on
build/eclipse <-- here is where eclipse compiles stuff2) add
<map:classpath>
<class-dir src="./build/eclipse"/>
<lib-dir src="./lib"/>
</map:classpath>to the sitemap above
3) add a symlink
$COCOON_HOME/build/webapp/mycocoonapp -> /code/mycocoonapp
et voila', you are able to 'mount' stuff in cocoon without even touching a single line in your cocoon installation, then you just have to have your proxypass setup so that http://host/mycocoonapp points to http://127.0.0.1:8888/mycocoonapp.
Easy, fast and secure.
Too bad it doesn't work! since 'lib-dir' resolves the '.' in './lib' as local to the cocoon context, instead of the location of the sitemap it's found in.
This is a mistake, IMO: a real block should *NOT* contain any information about where it has been mounted and this behavior requires it to do so, preventing the block to be mounted somewhere else transparently.
Is there any need for this behavior that I didn't consider?
-- Stefano.
