Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of joerg.heinicke@gmx.de designates
 213.165.64.20 as permitted sender)
Message-ID: <431A3C74.4030507@gmx.de>
Date: Sun, 04 Sep 2005 02:14:44 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.11) Gecko/20050728
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>
In-Reply-To: 
 <64511.194.149.247.8.1125761359.squirrel@webmail.paiwastoon.com.af>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 03.09.2005 17:29, Torsten Schlabach wrote:

> - Cocoon's build system has always relied on quite recent versions of Ant.

I don't think so. Cocoon's build system was always very stable. Though 
Cocoon was almost delivered with a very recent Ant, it almost ever used 
the features of these versions. I don't know exactly, but it might still 
be possible to build Cocoon with Ant pre 1.6.

> This sometimes meant a version of Ant which was never than the one that
> was built into Eclipse. This sometimes made it nessary to use an "external
> Ant" (the one that comes with the Cocoon tarball and therefore is external
> to Eclipse, i.e. not the built-in one).

The problem is just that Cocoon extends the Ant delivered with it, but 
not the newer version itself.

> Note: There is documentation available somewhere how to replace the Ant in
> Eclipse, but either I never made it work or did not find the time. Not
> sure anymore.

That's quite easy in general: Windows > Preferences > Ant > Runtime > 
Ant Home... > selecting the directory > finished.

> - Some external Ant tasks where needed that got shipped in the Cocoon
> tarball as sources. This meant that during the build process Ant built
> parts of itself so to say. This failed using the internal Ant.

This might be true. I never tried it with Cocoon's Ant because of its 
extensions. I don't know if you have to setup it differently, e.g. for 
the Loader class.

> I am not sure what has changed to solve this. Either these Ant tasks are
> not delivered in binary, so they can be put on the classpath of the
> internal Ant or someone just discovered they have been there all the time.
> You might want to check.

It has changed? I can't imagine.

> I again never took the time to find out what exactly the eclipse-project
> task does, but I presume it has something to do with aligning Eclipse's
> view of where to put the .class files with Cocoon's.

That's quite easy: It sets up an Eclipse project by creating .project 
and .classpath file.

> Part of the problem when you checkout Cocoon from SVN using Subclipse is
> that Eclipse will immediatelly start to detect source code folders and
> start to compile any Java classes it can find. (Partially failing.) This
> is happening before you get a chance to execute the eclipse-project
> target. It is a certain chicken and egg problem that I never found a good
> solutions for, except
> 
> 1. checkout using Subclipse
> 2. stop the build
> 3. close the project
> 4. use a command line outside eclipse, go to the cocoon dir in the Eclipse
> workspace and issue build.sh clean and build.sh eclipse-project
> 5. open the project in Eclipse again

Is this really a problem? You do not even need to close the project. Run 
"build eclipse-project" while the project is open. Refresh the project 
in Eclipse afterwards.

> There is something in Eclipse called "build a project from an existing Ant
> file", but I am not sure it will solve any of our problems.

I don't know how this should work at all.

> 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.

With newer Eclipse (3.1 or newer, don't know if this worked with older 
ones too) by putting an eclipse.ini into Eclipse's root dir:

-vmargs
-Xms256m
-Xmx512m

With older Eclipse by putting the 3 args into the command line call:

%ECLIPSE_HOME%\eclipse.exe -vmargs -Xms256m -Xmx512m

> - 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?

Therefore you don't need to run Cocoon inside Eclipse. Having a working 
hot code replacement with JDK 1.4 and remote debugging avoids the 
coupling of Cocoon and Eclipse. But I emphasized "working hot code 
replacement" because I never really got it why it works and why if not. 
Though the remote debugging is to be setup very easily, the hot code 
replacment seems to be more like a lottery.

Joerg