You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Lundquist <ml...@comcast.net> on 2005/09/02 20:36:15 UTC
Eclipse w/ 2.1.7
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—
Re: Eclipse w/ 2.1.7
Posted by Jorg Heymans <jh...@domek.be>.
Torsten Schlabach wrote:
> I wasn't even aware that this exists. Would you mind adding this to the
> Wiki page?
>
> Also it look as if there are different schools of "How to run / develop
> Cocoon in Eclipse". If both ways of doing it are valid and have advantages
> and disadvantages, we would maybe explain this in the Wiki page as well.
>
Well i looked at this [1] page, there is so much different (even
contradicting) stuff on there already that i decided not to cloud things
even more.
If you can find a good spot to add it there go ahead.
Regards
Jorg
[1] http://wiki.apache.org/cocoon/LoadInEclipse
Re: Eclipse w/ 2.1.7
Posted by Torsten Schlabach <ts...@apache.org>.
> FWIW i still do "build eclipse-project" even "build
> eclipse-customized-project". The latter sets up the source paths of the
> enabled blocks only, making eclipse+cocoon sources actually doable on
> lower spec machines. I keep svn+jetty outside of eclipse as both act
> too quirky when run from inside the ide.
I wasn't even aware that this exists. Would you mind adding this to the
Wiki page?
Also it look as if there are different schools of "How to run / develop
Cocoon in Eclipse". If both ways of doing it are valid and have advantages
and disadvantages, we would maybe explain this in the Wiki page as well.
Regards,
Torsten
>
> Mark Lundquist wrote:
>>
>> 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.
>
> FWIW i still do "build eclipse-project" even "build
> eclipse-customized-project". The latter sets up the source paths of the
> enabled blocks only, making eclipse+cocoon sources actually doable on
> lower spec machines. I keep svn+jetty outside of eclipse as both act
> too quirky when run from inside the ide.
>
>
> Jorg
>
>
Re: Eclipse w/ 2.1.7
Posted by Antonio Gallardo <ag...@agssa.net>.
Jorg Heymans wrote:
>Mark Lundquist wrote:
>
>
>>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.
>>
>>
>
>FWIW i still do "build eclipse-project" even "build
>eclipse-customized-project". The latter sets up the source paths of the
>enabled blocks only, making eclipse+cocoon sources actually doable on
>lower spec machines.
>
.... Actually, high spec machines take advantage too --> more free mem,
et al. ;-)
>I keep svn+jetty outside of eclipse as both act
>too quirky when run from inside the ide.
>
>
>Jorg
>
>
Best Regards,
Antonio Gallardo.
Re: Eclipse w/ 2.1.7
Posted by Sylvain Wallez <sy...@apache.org>.
Mark Lundquist wrote:
> Jorg Heymans wrote:
>
>> FWIW i still do "build eclipse-project" even "build
>> eclipse-customized-project". The latter sets up the source paths of the
>> enabled blocks only
>
>
> Hey, that is great... next time I won't have to cut down .classpath by
> hand :-)
>
> Why doesn't the regular eclipse-project target do that? Why would
> anybody want source paths of excluded blocks on their classpath?
Because when you develop Cocoon, you want to be sure that everything
compiles even if your webapp doesn't include all blocks!
> -=-=-=-=-
>
> Here's another one, going a little OT I guess, but... :-/
>
> I've set it up so that my Cocoon project is "remote", it's not
> contained in my Eclipse project (there's a symbolic link to it). I
> have the Cocoon src dirs in .classpath, but just for debugging... I
> don't want them to compile when I build my project (but of course I
> _do_ want Eclipse to compile my project-specific Java sources...) Any
> idea how to set that up?
You should simply associate the source code directory to cocoon.jar in
your project: select a jar file, right-click and select "properties/java
source attachment".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Eclipse w/ 2.1.7
Posted by Mark Lundquist <ml...@comcast.net>.
Jorg Heymans wrote:
> FWIW i still do "build eclipse-project" even "build
> eclipse-customized-project". The latter sets up the source paths of the
> enabled blocks only
Hey, that is great... next time I won't have to cut down .classpath by
hand :-)
Why doesn't the regular eclipse-project target do that? Why would
anybody want source paths of excluded blocks on their classpath?
-=-=-=-=-
Here's another one, going a little OT I guess, but... :-/
I've set it up so that my Cocoon project is "remote", it's not contained
in my Eclipse project (there's a symbolic link to it). I have the
Cocoon src dirs in .classpath, but just for debugging... I don't want
them to compile when I build my project (but of course I _do_ want
Eclipse to compile my project-specific Java sources...) Any idea how to
set that up?
Cheers,
—ml—
Re: Eclipse w/ 2.1.7
Posted by Jorg Heymans <jh...@domek.be>.
Mark Lundquist wrote:
>
> 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.
FWIW i still do "build eclipse-project" even "build
eclipse-customized-project". The latter sets up the source paths of the
enabled blocks only, making eclipse+cocoon sources actually doable on
lower spec machines. I keep svn+jetty outside of eclipse as both act
too quirky when run from inside the ide.
Jorg
Re: Eclipse w/ 2.1.7
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 4 Sep 2005, at 17:50, Torsten Schlabach wrote:
> > I never had this problem. I can even rename the project in Eclipse -
> > without changing the directory.
>
> Yes! You can rename it once it is importet, but in order to import
> it, names need to match!
Ah... Noted! :-P
Pier
Re: Eclipse w/ 2.1.7
Posted by Torsten Schlabach <ts...@apache.org>.
> I never had this problem. I can even rename the project in Eclipse -
> without changing the directory.
Yes! You can rename it once it is importet, but in order to import it,
names need to match!
Joerg Heinicke schrieb:
> On 04.09.2005 15:18, Pier Fumagalli wrote:
>
>> On this topic, I just ran "./build.sh eclipse-project" and when
>> importing in Eclipse it tells me "invalid project description". Note
>> that I don't use SVN embedded in Eclipse (too slow).
>>
>> Anyone had this problem before? Renaming the project name from
>> "Cocoon-2.1.8-dev" to "cocoon" (the name of the directory within my
>> workspace where Cocoon was checked out) fixed the problem.
>
>
> I never had this problem. I can even rename the project in Eclipse -
> without changing the directory.
>
> Jörg
Re: Eclipse w/ 2.1.7
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.09.2005 15:18, Pier Fumagalli wrote:
> On this topic, I just ran "./build.sh eclipse-project" and when
> importing in Eclipse it tells me "invalid project description". Note
> that I don't use SVN embedded in Eclipse (too slow).
>
> Anyone had this problem before? Renaming the project name from
> "Cocoon-2.1.8-dev" to "cocoon" (the name of the directory within my
> workspace where Cocoon was checked out) fixed the problem.
I never had this problem. I can even rename the project in Eclipse -
without changing the directory.
Jörg
Re: Eclipse w/ 2.1.7
Posted by Pier Fumagalli <pi...@betaversion.org>.
On this topic, I just ran "./build.sh eclipse-project" and when
importing in Eclipse it tells me "invalid project description". Note
that I don't use SVN embedded in Eclipse (too slow).
Anyone had this problem before? Renaming the project name from
"Cocoon-2.1.8-dev" to "cocoon" (the name of the directory within my
workspace where Cocoon was checked out) fixed the problem.
Pier
Re: Eclipse w/ 2.1.7
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez wrote:
> Personally, I use:
> - svn from the command line
> - eclipse-project to build .classpath and .project files
> - separate build ("build.sh webapp")
> - separate launch ("cocoon.sh servlet")
> - debug in Eclipse by connecting to a remote VM started using
> "cocoon.sh servlet-debug".
Yep. This is the way I do too. Again, thanks to Upayavira for giving me
a great hint long time ago! :-)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106564291827022
Best Regards,
Antonio Gallardo
Re: Eclipse w/ 2.1.7
Posted by Torsten Schlabach <ts...@apache.org>.
Sylvain,
> LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
> shows how complicated its build system is :-)
Building Eclipse with Coocoon. This is a new one, and you're right, it
will be difficult.
But seriously:
If it was all so clear, why do we have recurring discussions on this
topic on this list and no single, definitive Howto somewhere? I get
quite fed up recently when I lost a whole day trying to set up a Cocoon
development environment that allowed me just what I said: A small cycle
time for a roundtrip.
I had done a lot with Cocoon, so mostly it worked for me to just extract
the tarball, build it and then work in the sitemap and XML files, but
now I had to work with some code inside Cocoon directly.
And looking at that Wiki page (LoadInEclipse) shows a lot of ambiguity
with a lot of people. It's fine if you figured a solution that works for
you, but I think it's worth trying to put that definitive howto together.
I remember when I brushed up that Wiki page last time that there were
lots of problems; I had researched for a day or so; and again there were
lots of ambigous discussions on the mailing list.
In addition, there seem to be some features that I guess few people were
aware off, such as the eclipse-customized-project target and some of the
tipps you mention in your e-mail.
But thank you for the hints (also from the others). I'll hopefully find
the time to go over that Wiki page once again and thus save others the
time to figure out every little piece themselves.
Regards,
Torsten
Sylvain Wallez schrieb:
> Torsten Schlabach wrote:
>
>> 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.
>>
>>
>
> LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
> shows how complicated its build system is :-)
>
> Personally, I use:
> - svn from the command line
> - eclipse-project to build .classpath and .project files
> - separate build ("build.sh webapp")
> - separate launch ("cocoon.sh servlet")
> - debug in Eclipse by connecting to a remote VM started using "cocoon.sh
> servlet-debug".
>
>> 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.
>>
>>
>
> AFAIK, when you launch a program from Eclipse, it creates a new VM.
>
> The reason why I personally have never launched Cocoon from Eclipse is
> that I have most of the time a Cocoon instance running on my laptop,
> whose lifecycle is thus decoupled from the lifetime of the IDE.
>
>> - 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?
>>
>>
>
> It is fun, and you have it *right now* in trunk :-) Just use the
> classpath-per-sitemap feature in trunk!
>
> Another way of speeding up roundrips when you need to restart Jetty is
> to use the ParanoidClassloader and give it a parnoid-classpath (in
> web.xml) that points to the directory where Eclipse writes class files.
> Here's my paranoid-classpath:
> class-dir: build/eclipse/classes
> lib-dir: build/webapp/WEB-INF/lib
>
> The only thing you've got to take care of (in 2.1.x, not trunk) is to
> delete cocoon.roles from build/eclipse/classes, so that the full one in
> WEB-INF/lib (containing all block-defined roles) is used.
>
> You then no more need "build.sh webapp", unless you make changes in
> configuration files.
>
> Ah, and finally, I use the mount-table matcher a lot to directly test
> modifications in src/webapp without having to go through the build
> process. Here's my mount-table.xml:
>
> <mount-table>
> <mount uri-prefix="forms/" src="../../src/blocks/forms/samples/"/>
> <mount uri-prefix="petstore/" src="../../src/blocks/petstore/samples/"/>
> <mount uri-prefix="test/" src="../../src/webapp/samples/test/"/>
>
> <!-- and a lot more, pointing to prototypes and projects on my HD, thus
> avoiding to copy Cocoon all over the place -->
> </mount-table>
>
> Sylvain
>
Re: Eclipse w/ 2.1.7
Posted by Torsten Schlabach <ts...@apache.org>.
Sylvain,
> LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
> shows how complicated its build system is :-)
Building Eclipse with Coocoon. This is a new one, and you're right, it
will be difficult.
But seriously:
If it was all so clear, why do we have recurring discussions on this
topic on this list and no single, definitive Howto somewhere? I get
quite fed up recently when I lost a whole day trying to set up a Cocoon
development environment that allowed me just what I said: A small cycle
time for a roundtrip.
I had done a lot with Cocoon, so mostly it worked for me to just extract
the tarball, build it and then work in the sitemap and XML files, but
now I had to work with some code inside Cocoon directly.
And looking at that Wiki page (LoadInEclipse) shows a lot of ambiguity
with a lot of people. It's fine if you figured a solution that works for
you, but I think it's worth trying to put that definitive howto together.
I remember when I brushed up that Wiki page last time that there were
lots of problems; I had researched for a day or so; and again there were
lots of ambigous discussions on the mailing list.
In addition, there seem to be some features that I guess few people were
aware off, such as the eclipse-customized-project target and some of the
tipps you mention in your e-mail.
But thank you for the hints (also from the others). I'll hopefully find
the time to go over that Wiki page once again and thus save others the
time to figure out every little piece themselves.
Regards,
Torsten
Sylvain Wallez schrieb:
> Torsten Schlabach wrote:
>
>> 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.
>>
>>
>
> LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
> shows how complicated its build system is :-)
>
> Personally, I use:
> - svn from the command line
> - eclipse-project to build .classpath and .project files
> - separate build ("build.sh webapp")
> - separate launch ("cocoon.sh servlet")
> - debug in Eclipse by connecting to a remote VM started using "cocoon.sh
> servlet-debug".
>
>> 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.
>>
>>
>
> AFAIK, when you launch a program from Eclipse, it creates a new VM.
>
> The reason why I personally have never launched Cocoon from Eclipse is
> that I have most of the time a Cocoon instance running on my laptop,
> whose lifecycle is thus decoupled from the lifetime of the IDE.
>
>> - 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?
>>
>>
>
> It is fun, and you have it *right now* in trunk :-) Just use the
> classpath-per-sitemap feature in trunk!
>
> Another way of speeding up roundrips when you need to restart Jetty is
> to use the ParanoidClassloader and give it a parnoid-classpath (in
> web.xml) that points to the directory where Eclipse writes class files.
> Here's my paranoid-classpath:
> class-dir: build/eclipse/classes
> lib-dir: build/webapp/WEB-INF/lib
>
> The only thing you've got to take care of (in 2.1.x, not trunk) is to
> delete cocoon.roles from build/eclipse/classes, so that the full one in
> WEB-INF/lib (containing all block-defined roles) is used.
>
> You then no more need "build.sh webapp", unless you make changes in
> configuration files.
>
> Ah, and finally, I use the mount-table matcher a lot to directly test
> modifications in src/webapp without having to go through the build
> process. Here's my mount-table.xml:
>
> <mount-table>
> <mount uri-prefix="forms/" src="../../src/blocks/forms/samples/"/>
> <mount uri-prefix="petstore/" src="../../src/blocks/petstore/samples/"/>
> <mount uri-prefix="test/" src="../../src/webapp/samples/test/"/>
>
> <!-- and a lot more, pointing to prototypes and projects on my HD, thus
> avoiding to copy Cocoon all over the place -->
> </mount-table>
>
> Sylvain
>
Re: Eclipse w/ 2.1.7
Posted by Sylvain Wallez <sy...@apache.org>.
Torsten Schlabach wrote:
>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.
>
>
LOL :-) The fact that it's so difficult to build Eclipse with Cocoon
shows how complicated its build system is :-)
Personally, I use:
- svn from the command line
- eclipse-project to build .classpath and .project files
- separate build ("build.sh webapp")
- separate launch ("cocoon.sh servlet")
- debug in Eclipse by connecting to a remote VM started using "cocoon.sh
servlet-debug".
>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.
>
>
AFAIK, when you launch a program from Eclipse, it creates a new VM.
The reason why I personally have never launched Cocoon from Eclipse is
that I have most of the time a Cocoon instance running on my laptop,
whose lifecycle is thus decoupled from the lifetime of the IDE.
>- 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?
>
>
It is fun, and you have it *right now* in trunk :-) Just use the
classpath-per-sitemap feature in trunk!
Another way of speeding up roundrips when you need to restart Jetty is
to use the ParanoidClassloader and give it a parnoid-classpath (in
web.xml) that points to the directory where Eclipse writes class files.
Here's my paranoid-classpath:
class-dir: build/eclipse/classes
lib-dir: build/webapp/WEB-INF/lib
The only thing you've got to take care of (in 2.1.x, not trunk) is to
delete cocoon.roles from build/eclipse/classes, so that the full one in
WEB-INF/lib (containing all block-defined roles) is used.
You then no more need "build.sh webapp", unless you make changes in
configuration files.
Ah, and finally, I use the mount-table matcher a lot to directly test
modifications in src/webapp without having to go through the build
process. Here's my mount-table.xml:
<mount-table>
<mount uri-prefix="forms/" src="../../src/blocks/forms/samples/"/>
<mount uri-prefix="petstore/" src="../../src/blocks/petstore/samples/"/>
<mount uri-prefix="test/" src="../../src/webapp/samples/test/"/>
<!-- and a lot more, pointing to prototypes and projects on my HD, thus
avoiding to copy Cocoon all over the place -->
</mount-table>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Eclipse w/ 2.1.7
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Re: Eclipse w/ 2.1.7
Posted by Torsten Schlabach <ts...@apache.org>.
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
>
>