You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2003/07/15 01:22:46 UTC
Re: eclipse classpath
Why exactly? I only found out - when setting output path to
WEB-INF/classes - that Eclipse kicked the complete content and replaces
the xpatch'ed cocoon.roles. I don't have another problem with Eclipse.
Carsten added a target 'eclipse-prepare-webapp' to circumvent this
problem and restore the xpatch'ed cocoon.roles.
Joerg
Geoff Howard wrote:
> I just noticed that eclipse now has support for different destination
> folders for each source folder, something that was needed before one
> could have eclipse compile into the same build dir that cocoon does. Is
> there value in setting this up? (it's just a matter of adding an output
> attribute on the classpathentry element in .classpath.
>
> I'd be particularly interested to hear from anyone who's tried it and
> found problems or benefits. I'd imagine that the cocoon build would
> go faster, and possibly build clean would be less often necessary.
>
> Geoff
Re: eclipse classpath
Posted by Joerg Heinicke <jo...@gmx.de>.
Geoff Howard wrote:
>> Yes, the build takes again very much time ... and memory. Especially
>> because of JavaDoc, that creates 3.500 files and copies them
>> afterwards. And copying so many so little files takes very much time :-(
>
> Maybe the copy is unnecessary?
Yes, I guess so :) The output directory must simply be changed. The
question is if this is ok?
>> Furthermore our cocoon.war is between 32 and 37 MB (I don't know why
>> it's so different. I used it last week for JSP Resin tests.) Do we
>> have to much in the repository? Could we clean up anything?
>
> Is that with all blocks? With most of them excluded I think it is much
> smaller.
Of course. About 30 MB core would be to much ;-)
Joerg
Re: eclipse classpath
Posted by Geoff Howard <co...@leverageweb.com>.
Joerg Heinicke wrote:
> Geoff Howard wrote:
>
>> BUILD SUCCESSFUL
>> Total time: 14 minutes 29 seconds
>
> Yes, the build takes again very much time ... and memory. Especially
> because of JavaDoc, that creates 3.500 files and copies them afterwards.
> And copying so many so little files takes very much time :-(
Maybe the copy is unnecessary?
> Furthermore our cocoon.war is between 32 and 37 MB (I don't know why
> it's so different. I used it last week for JSP Resin tests.) Do we have
> to much in the repository? Could we clean up anything?
Is that with all blocks? With most of them excluded I think it is much
smaller.
>>> I don't have another problem with Eclipse.
>>
>> Me either (except the debugger and flowscript possibly)
>
> Ok, little problems:
> 1. CVS commands take much time (much more than WinCVS).
> 2. CVS does not support a local repository using local: and I wonder why.
> 3. There is no really good XML editor: tabs => spaces, auto-indent,
> configuring the colors, catalogues as in Cocoon build. I tried XMLbuddy
> and Sunbow. Oxygen (http://www.oxygenxml.com/) seems to support all I
> need, but costs money ...
I haven't noticed the problem with slow cvs - I was just using
commandline (via cygwin) and haven't tried using local:. I have had
occasional problems with eclipse failing and leaving a lock file, and
then repeatedly failing without telling me that the lock file was the
problem. Is there a way to execute raw cvs from the command line in the
cvs console? I guess this is OT for cocoon though.
Geoff
Re: eclipse classpath
Posted by Joerg Heinicke <jo...@gmx.de>.
Geoff Howard wrote:
> BUILD SUCCESSFUL
> Total time: 14 minutes 29 seconds
Yes, the build takes again very much time ... and memory. Especially
because of JavaDoc, that creates 3.500 files and copies them afterwards.
And copying so many so little files takes very much time :-(
Furthermore our cocoon.war is between 32 and 37 MB (I don't know why
it's so different. I used it last week for JSP Resin tests.) Do we have
to much in the repository? Could we clean up anything?
>> I don't have another problem with Eclipse.
>
> Me either (except the debugger and flowscript possibly)
Ok, little problems:
1. CVS commands take much time (much more than WinCVS).
2. CVS does not support a local repository using local: and I wonder why.
3. There is no really good XML editor: tabs => spaces, auto-indent,
configuring the colors, catalogues as in Cocoon build. I tried XMLbuddy
and Sunbow. Oxygen (http://www.oxygenxml.com/) seems to support all I
need, but costs money ...
> By the way, are you running ant from inside eclipse, or do you use
> build.sh? I gave up on the first and haven't tried lately.
As mentioned: endorsed libs problem :-( And nothing tried to solve it.
Joerg
RE: eclipse classpath
Posted by Reinhard Pötz <re...@gmx.net>.
From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Joerg Heinicke wrote:
> > Why exactly? I only found out - when setting output path to
> > WEB-INF/classes - that Eclipse kicked the complete content
> and replaces
> > the xpatch'ed cocoon.roles.
>
> Maybe that is the smarter way to go. I've been wanting to
> set the output path to the same as the build before
> prepare-webapp (i.e.,
> build/cocoon-2.1rc1dev/classes,
> build/cocoon-2.1rc1dev/scratchpad/dest,
> and so on for each source path) so I could let eclipse do the
> compiling (since it usually already has anyway) but still use
> the regular build. I don't know that eclipse's compiling is
> orders of magnitude better, but
> it does it incrementally.
>
> But compiling/copying straight to WEB-INF would save even
> more time in
> some situations. Well, I'll start experimenting and see what
> I learn.
> Anything to improve:
> BUILD SUCCESSFUL
> Total time: 14 minutes 29 seconds
Therefore I added the paramter
ide.eclipse.outputdir
to build.properties. Here you can set your WEB-INF/classes
directory and compile directly into your servlet container. This
works pretty good for me. If you need more fine grained output
directories this should be possible but I haven't needed it yet.
HTH
Reinhard
RE: eclipse classpath
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Joerg Heinicke wrote:
>
> You start your servlet container from inside Eclipse? I start it from
> command line and only attach for remote debugging.
>
Yes, sure; it's the fastest approach for me. You actually don't need
the command line anymore (except for building the webapp the first
time).
>
> I have set the eclipse output to WEB-INF/classes, so that changes aren't
> lost after servlet container restart. So I only need to restore the
> patched roles file. What about
>
> <!-- Prepares the webapp to make it directly usable with the eclipse
> project -->
> <target name="eclipse-webapp-prepare" depends="prepare,
> eclipse-webapp-delete-jars, eclipse-webapp-restore-roles"
> description="Prepares the webapp directory to make it usable
> within Eclipse"/>
>
> <target name="eclipse-webapp-restore-roles">
> <copy file="${build.dest}/org/apache/cocoon/cocoon.roles"
> tofile="${build.webapp}/WEB-INF/classes/org/apache/cocoon/cocoon.roles"
> overwrite="yes"/>
> </target>
>
> <target name="eclipse-webapp-delete-jars">
> <!-- delete all jars, they are already included in the project -->
> <delete>
> <fileset dir="${build.webapp}/WEB-INF/lib" includes="*.jar"/>
> </delete>
> </target>
>
Yes, ok, works for me.
Carsten
Re: eclipse classpath
Posted by Joerg Heinicke <jo...@gmx.de>.
>>But why removing all jars? I used it the last weeks without removing the
>>jars. Tomcat
>>(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html)
>>(and also Jetty from my experience) look first at /WEB-INF/classes,
>>second /WEB-INF/lib/*.jar for the needed classes. This would also allow
>>the outside usage of the webapp.
>
> Yes, that's try, but if you create a launch configuration for eclipse,
> it automatically adds all jars from your project to your classpath. So,
> you have all jars in the startup classpath and in WEB-INF/lib and this
> can cause problems as the class loaded via WEB-INF/lib is not the same
> as when loaded via the startup classpath.
You start your servlet container from inside Eclipse? I start it from
command line and only attach for remote debugging.
> So, this is a simple but working solution for eclipse.
> And, as the compiled classes from eclipse are not copied to WEB-INF/classes
> but to the usual configured output folder, you would get into problems
> when the cocoon.jars are still in WEB-INF/lib.
I have set the eclipse output to WEB-INF/classes, so that changes aren't
lost after servlet container restart. So I only need to restore the
patched roles file. What about
<!-- Prepares the webapp to make it directly usable with the eclipse
project -->
<target name="eclipse-webapp-prepare" depends="prepare,
eclipse-webapp-delete-jars, eclipse-webapp-restore-roles"
description="Prepares the webapp directory to make it usable
within Eclipse"/>
<target name="eclipse-webapp-restore-roles">
<copy file="${build.dest}/org/apache/cocoon/cocoon.roles"
tofile="${build.webapp}/WEB-INF/classes/org/apache/cocoon/cocoon.roles"
overwrite="yes"/>
</target>
<target name="eclipse-webapp-delete-jars">
<!-- delete all jars, they are already included in the project -->
<delete>
<fileset dir="${build.webapp}/WEB-INF/lib" includes="*.jar"/>
</delete>
</target>
Joerg
RE: eclipse classpath
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Joerg Heinicke wrote:
>
> Carsten Ziegeler wrote:
> > Using eclipse is really very simple, you only have to invoke ant once.
> > Just add a launch configuration to your project that directly starts
> > jetty and uses the build/webapp directory for the webapp.
> >
> > Now build Cocoon once using ant, this creates the webapp directory,
> > copies the samples etc; invoke the eclipse-project and eclipse-webapp
> > targets. This updates your eclipse project, removes all jars from
> > WEB-INF/lib and restores the cocoon.roles.
>
> But why removing all jars? I used it the last weeks without removing the
> jars. Tomcat
> (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html)
> (and also Jetty from my experience) look first at /WEB-INF/classes,
> second /WEB-INF/lib/*.jar for the needed classes. This would also allow
> the outside usage of the webapp.
>
Yes, that's try, but if you create a launch configuration for eclipse,
it automatically adds all jars from your project to your classpath. So,
you have all jars in the startup classpath and in WEB-INF/lib and this
can cause problems as the class loaded via WEB-INF/lib is not the same
as when loaded via the startup classpath.
So, this is a simple but working solution for eclipse.
And, as the compiled classes from eclipse are not copied to WEB-INF/classes
but to the usual configured output folder, you would get into problems
when the cocoon.jars are still in WEB-INF/lib.
> >>From now on you can directly compile, edit and debug in eclipse and
> > simply launch the jetty launch target from within eclipse.
> > You only have to invoke ant if you change something in the configuration
> > or the samples but not for java code.
> > PS: I tried to created the launch configuration via ant but failed :(
>
> I could neither run Ant inside Eclipse - the old endorsed libs problem,
> somebody mentioned it already on the list, but I don't know if this
> problem was solved.
>
I don't run ant from Eclipse (at least for cocoon); i use the cli.
Carsten
Re: eclipse classpath
Posted by Joerg Heinicke <jo...@gmx.de>.
Carsten Ziegeler wrote:
> Using eclipse is really very simple, you only have to invoke ant once.
> Just add a launch configuration to your project that directly starts
> jetty and uses the build/webapp directory for the webapp.
>
> Now build Cocoon once using ant, this creates the webapp directory,
> copies the samples etc; invoke the eclipse-project and eclipse-webapp
> targets. This updates your eclipse project, removes all jars from
> WEB-INF/lib and restores the cocoon.roles.
But why removing all jars? I used it the last weeks without removing the
jars. Tomcat
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html)
(and also Jetty from my experience) look first at /WEB-INF/classes,
second /WEB-INF/lib/*.jar for the needed classes. This would also allow
the outside usage of the webapp.
>>>From now on you can directly compile, edit and debug in eclipse and
> simply launch the jetty launch target from within eclipse.
> You only have to invoke ant if you change something in the configuration
> or the samples but not for java code.
> PS: I tried to created the launch configuration via ant but failed :(
I could neither run Ant inside Eclipse - the old endorsed libs problem,
somebody mentioned it already on the list, but I don't know if this
problem was solved.
Joerg
RE: eclipse classpath
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Using eclipse is really very simple, you only have to invoke ant once.
Just add a launch configuration to your project that directly starts
jetty and uses the build/webapp directory for the webapp.
Now build Cocoon once using ant, this creates the webapp directory,
copies the samples etc; invoke the eclipse-project and eclipse-webapp
targets. This updates your eclipse project, removes all jars from
WEB-INF/lib and restores the cocoon.roles.
>From now on you can directly compile, edit and debug in eclipse and
simply launch the jetty launch target from within eclipse.
You only have to invoke ant if you change something in the configuration
or the samples but not for java code.
PS: I tried to created the launch configuration via ant but failed :(
Carsten
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Tuesday, July 15, 2003 4:23 AM
> To: dev@cocoon.apache.org
> Subject: Re: eclipse classpath
>
>
> Joerg Heinicke wrote:
> > Why exactly? I only found out - when setting output path to
> > WEB-INF/classes - that Eclipse kicked the complete content and replaces
> > the xpatch'ed cocoon.roles.
>
> Maybe that is the smarter way to go. I've been wanting to set the
> output path to the same as the build before prepare-webapp (i.e.,
> build/cocoon-2.1rc1dev/classes, build/cocoon-2.1rc1dev/scratchpad/dest,
> and so on for each source path) so I could let eclipse do the compiling
> (since it usually already has anyway) but still use the regular build.
> I don't know that eclipse's compiling is orders of magnitude better, but
> it does it incrementally.
>
> But compiling/copying straight to WEB-INF would save even more time in
> some situations. Well, I'll start experimenting and see what I learn.
> Anything to improve:
> BUILD SUCCESSFUL
> Total time: 14 minutes 29 seconds
>
> > I don't have another problem with Eclipse.
>
> Me either (except the debugger and flowscript possibly)
>
> By the way, are you running ant from inside eclipse, or do you use
> build.sh? I gave up on the first and haven't tried lately.
>
> > Carsten added a target 'eclipse-prepare-webapp' to circumvent this
> > problem and restore the xpatch'ed cocoon.roles.
>
> I'll see what he's doing there - maybe it'll give some ideas.
>
> Thanks,
> Geoff
>
> >
> > Geoff Howard wrote:
> >
> >> I just noticed that eclipse now has support for different destination
> >> folders for each source folder, something that was needed before one
> >> could have eclipse compile into the same build dir that cocoon does.
> >> Is there value in setting this up? (it's just a matter of adding an
> >> output attribute on the classpathentry element in .classpath.
> >>
> >> I'd be particularly interested to hear from anyone who's tried it and
> >> found problems or benefits. I'd imagine that the cocoon build would
> >> go faster, and possibly build clean would be less often necessary.
> >>
> >> Geoff
> >
> >
> >
> >
> >
>
>
Re: eclipse classpath
Posted by Geoff Howard <co...@leverageweb.com>.
Joerg Heinicke wrote:
> Why exactly? I only found out - when setting output path to
> WEB-INF/classes - that Eclipse kicked the complete content and replaces
> the xpatch'ed cocoon.roles.
Maybe that is the smarter way to go. I've been wanting to set the
output path to the same as the build before prepare-webapp (i.e.,
build/cocoon-2.1rc1dev/classes, build/cocoon-2.1rc1dev/scratchpad/dest,
and so on for each source path) so I could let eclipse do the compiling
(since it usually already has anyway) but still use the regular build.
I don't know that eclipse's compiling is orders of magnitude better, but
it does it incrementally.
But compiling/copying straight to WEB-INF would save even more time in
some situations. Well, I'll start experimenting and see what I learn.
Anything to improve:
BUILD SUCCESSFUL
Total time: 14 minutes 29 seconds
> I don't have another problem with Eclipse.
Me either (except the debugger and flowscript possibly)
By the way, are you running ant from inside eclipse, or do you use
build.sh? I gave up on the first and haven't tried lately.
> Carsten added a target 'eclipse-prepare-webapp' to circumvent this
> problem and restore the xpatch'ed cocoon.roles.
I'll see what he's doing there - maybe it'll give some ideas.
Thanks,
Geoff
>
> Geoff Howard wrote:
>
>> I just noticed that eclipse now has support for different destination
>> folders for each source folder, something that was needed before one
>> could have eclipse compile into the same build dir that cocoon does.
>> Is there value in setting this up? (it's just a matter of adding an
>> output attribute on the classpathentry element in .classpath.
>>
>> I'd be particularly interested to hear from anyone who's tried it and
>> found problems or benefits. I'd imagine that the cocoon build would
>> go faster, and possibly build clean would be less often necessary.
>>
>> Geoff
>
>
>
>
>