> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of
> Ovidiu Predescu
>
> Folks,
>
> During the development of Schecoon I really enjoyed the fast build
> time I would get compared to building Cocoon. On my machine doing a
> "./build.sh -Dinclude.webapp.libs=true webapp" from scratch in Cocoon
> takes 2 minutes and 10 seconds. In Schecoon a "./build.sh webapp"
> takes 25 seconds to complete.
If you simply skip <jar/> step in the "webapp" target this alone saves
lots of time. I have ./build/cocoon/webapp deployed in the tomcat and
have a patched build.xml:
Index: build.xml
===================================================================
RCS file: /home/cvspublic/xml-cocoon2/build.xml,v
retrieving revision 1.197
diff -u -r1.197 build.xml
--- build.xml 10 Apr 2002 06:57:27 -0000 1.197
+++ build.xml 10 Apr 2002 21:24:15 -0000
@@ -1206,8 +1210,11 @@
<taskdef name="manifest-tool" classname="ManifestToolTask"
classpath="${tools.dir}/anttasks"/>
- <manifest-tool directory="${build.war}/WEB-INF/lib"
manifest="${build.war}/WEB-INF/Manifest.mf"/>
+ <manifest-tool directory="${build.war}/WEB-INF/lib"
+ manifest="${build.war}/WEB-INF/Manifest.mf"/>
+<!--
<jar jarfile="${build.dir}/${name}.war" basedir="${build.war}"
includes="**" manifest="${build.war}/WEB-INF/Manifest.mf"/>
+-->
</target>
<!--
=================================================================== -->
Why not just add intermediate target, something like "webapp-dir"?
Vadim
> I don't know how others can stand long build times, but for me it
> makes me feel I'm loosing time, and reminds me of the old days of
> developing C programs, where the link time was outrageously long. I do
> lots of tricks to minimize the time for the edit-compile-run cycle,
> but I'm still not satisfied.
>
> So I propose splitting Cocoon in smaller parts, based on high-level
> functionality, which generate their own results in a common build
> area. This would be kind-of the new Avalon Excalibur system, although
> a bit different. A directory containing a high-level functionality
> would contain not only the code, but documentation and samples as
> well.
>
> For example the continuations based flow, would be in a directory
> called "flow". This directory would include everything Schecoon
> contains right now, components, examples, and documentation. Another
> directory would be "forms", which would follow a similar pattern. And
> so on.
>
> Each of these directories would have their own build.xml file. The top
> level build.xml would create a common build directory, which will hold
> all the results, and invoke the build in all the
> subdirectories. Building in a subdirectory compiles the Java code, and
> puts all the jar files in common build area. It would copy all the
> documentation in the appropriate directory in the common build area,
> and would add an entry using the XConf-tool in the main sitemap for
> it.
>
> This way implementing a new functionality becomes very localized, and
> doesn't result in rebuilding a large jar file. Maybe this will fit
> nicely into the Cocoon block idea as well, I don't know.
>
> The disadvantage is that instead of having one cocoon.jar file, we'll
> have many smaller jar files that have to be distributed. But with
> Cocoon blocks, this should not be an issue anymore, since they'll be
> hidden in the Cocoon distribution.
>
> Any thoughts on this?
>
> Thanks,
> --
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs,
other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
