Torsten Schlabach wrote:
Hi again,
I'm going to "test with 2.1.7"... but can somebody clarify what was
changed in in 2.1.8 to obviate the "old way"? Apparently in 2.1.8, the
"build.sh eclipse-project" is no longer necessary? Anyway, if someone
cares to provide some hints for me on this, I'd be glad to update the
Wiki.
I am not sure, but ... I think we are collectively making progress on this
list in getting this sorted out.
LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
shows how complicated its build system is :-)
Personally, I use:
- svn from the command line
- eclipse-project to build .classpath and .project files
- separate build ("build.sh webapp")
- separate launch ("cocoon.sh servlet")
- debug in Eclipse by connecting to a remote VM started using "cocoon.sh
servlet-debug".
Finally, two more things to think about:
- Many people have been reporting that they develop in Eclipse, but then
run Cocoon outside as it is getting pretty slow otherwise. I would presume
this is for memory reasons as Cocoon and Eclipse will share the same VM
(with a -Mx=128M ???) if you run Cocoon inside Eclipse. I haven't found
out how to give the VM that the Eclipse workbench is running in more
memory upfront.
AFAIK, when you launch a program from Eclipse, it creates a new VM.
The reason why I personally have never launched Cocoon from Eclipse is
that I have most of the time a Cocoon instance running on my laptop,
whose lifecycle is thus decoupled from the lifetime of the IDE.
- It might have advantages to run Cocoon inside Eclipse if we ever manage
to make Eclipse write a class file to the appropriate location in the
webapp and reload it inside Jetty. Imaging you are developing your own
Cocoon component (Transformer, Generator). You make a code change, hit
"Save", the class gets compiled and re-loaded in Jetty and you can do
straigt to your webbrowser, hit Reload there and thus test your component.
Wouldn't that be fun?
It is fun, and you have it *right now* in trunk :-) Just use the
classpath-per-sitemap feature in trunk!
Another way of speeding up roundrips when you need to restart Jetty is
to use the ParanoidClassloader and give it a parnoid-classpath (in
web.xml) that points to the directory where Eclipse writes class files.
Here's my paranoid-classpath:
class-dir: build/eclipse/classes
lib-dir: build/webapp/WEB-INF/lib
The only thing you've got to take care of (in 2.1.x, not trunk) is to
delete cocoon.roles from build/eclipse/classes, so that the full one in
WEB-INF/lib (containing all block-defined roles) is used.
You then no more need "build.sh webapp", unless you make changes in
configuration files.
Ah, and finally, I use the mount-table matcher a lot to directly test
modifications in src/webapp without having to go through the build
process. Here's my mount-table.xml:
<mount-table>
<mount uri-prefix="forms/" src="../../src/blocks/forms/samples/"/>
<mount uri-prefix="petstore/" src="../../src/blocks/petstore/samples/"/>
<mount uri-prefix="test/" src="../../src/webapp/samples/test/"/>
<!-- and a lot more, pointing to prototypes and projects on my HD, thus
avoiding to copy Cocoon all over the place -->
</mount-table>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
