cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject [PROPOSAL] splitting Cocoon
Date Wed, 10 Apr 2002 20:39:33 GMT
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.

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