cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Eclipse w/ 2.1.7
Date Sun, 04 Sep 2005 00:14:44 GMT
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 clean and 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:


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.


View raw message