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
|