cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Eclipse w/ 2.1.7
Date Sat, 03 Sep 2005 16:03:01 GMT
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


Mime
View raw message