Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <431AAC9B.4080002@apache.org>
Date: Sun, 04 Sep 2005 10:13:15 +0200
From: Torsten Schlabach <tschlabach@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Eclipse w/ 2.1.7
References: <dfa62v$i1j$1@sea.gmane.org>
 <64511.194.149.247.8.1125761359.squirrel@webmail.paiwastoon.com.af>
 <4319C935.3050408@apache.org>
In-Reply-To: <4319C935.3050408@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain,

> LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
> shows how complicated its build system is :-)

Building Eclipse with Coocoon. This is a new one, and you're right, it
will be difficult.

But seriously:

If it was all so clear, why do we have recurring discussions on this
topic on this list and no single, definitive Howto somewhere? I get
quite fed up recently when I lost a whole day trying to set up a Cocoon
development environment that allowed me just what I said: A small cycle
time for a roundtrip.

I had done a lot with Cocoon, so mostly it worked for me to just extract
the tarball, build it and then work in the sitemap and XML files, but
now I had to work with some code inside Cocoon directly.

And looking at that Wiki page (LoadInEclipse) shows a lot of ambiguity
with a lot of people. It's fine if you figured a solution that works for
you, but I think it's worth trying to put that definitive howto together.

I remember when I brushed up that Wiki page last time that there were
lots of problems; I had researched for a day or so; and again there were
lots of ambigous discussions on the mailing list.

In addition, there seem to be some features that I guess few people were
aware off, such as the eclipse-customized-project target and some of the
tipps you mention in your e-mail.

But thank you for the hints (also from the others). I'll hopefully find
the time to go over that Wiki page once again and thus save others the
time to figure out every little piece themselves.

Regards,
Torsten


Sylvain Wallez schrieb:
> 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
>