cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Schlabach" <tschlab...@apache.org>
Subject Re: Eclipse w/ 2.1.7
Date Sat, 03 Sep 2005 15:29:19 GMT
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.

Problems in the past when trying to build Cocoon in Eclipse and pretending
it was "nothing special" included this as far as I remember:

- Cocoon's build system has always relied on quite recent versions of Ant.
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).

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.

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

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.

Nailing it down a bit more, I find that there are two separat conncerns:

- Which Ant? Internal or External? (while looking at versions as well)
- eclipse-project or not?

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.

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

Of couse if you use a command line client to do the checkout, you can run
build.sh eclipse-project prior to even importing the project for the first
time into Eclipse.

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.

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.

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

Regards,
Torsten


>
> Hi,
>
> I've been studying the cocoon w/ eclipse wiki page
> (http://wiki.apache.org/cocoon/LoadInEclipse)... (thanks Torsten S. for
> updating! :-)
>
> The part under "Older Material" now says:
>
> 	"--- The stuff below may be deprecated as of 2.1.8-dev. It was
> definitely the way to go in 2.1.6. Maybe someone can take the time and
> test with 2.1.7. We should keep it around for people who need to stick
> to older releases for production support for a while."
>
>
> 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.
>
> Actually the Wiki page is a little confusing because it appears to maybe
> conflate two orthogonal concerns: 2.1.8 vs. 2.1.[67], and Subclipse vs.
> importing from the distribution...?
>
> Any add'l info appreciated! :-)
> —ml—
>
>


Mime
View raw message