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
