cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: [PROPOSAL] splitting Cocoon
Date Wed, 10 Apr 2002 21:27:40 GMT
> From: [] 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
> "./ -Dinclude.webapp.libs=true webapp" from scratch in Cocoon
> takes 2 minutes and 10 seconds. In Schecoon a "./ 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" 
-    <manifest-tool directory="${build.war}/WEB-INF/lib"
+    <manifest-tool directory="${build.war}/WEB-INF/lib"
+                   manifest="${build.war}/WEB-INF/"/>
     <jar jarfile="${build.dir}/${name}.war" basedir="${build.war}"
includes="**" manifest="${build.war}/WEB-INF/"/>
=================================================================== -->

Why not just add intermediate target, something like "webapp-dir"?


> 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 <>
> (GNU, Emacs,
other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message