cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [PROPOSAL] splitting Cocoon
Date Wed, 10 Apr 2002 21:27:40 GMT
> From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com] 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 <ovidiu@cup.hp.com>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs,
other stuff)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message