Ovidiu Predescu wrote:
>
> 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.
Sorry but I don't get it: this happens when you do it the first time and
I agree it's pretty slow, but everytime you change something, Ant
recompiles only the files that changed. I normally have compile times of
10 seconds on my PentiumII 366 (which isn't exactly a lightspeed
machine)
> 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.
Yes, but I don't think it makes sense to do this *before* the Cocoon
blocks are developped.
> 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.
Hmmm, I'd like to see a detailed action plan before starting to do
something like this. Flow and forms are exactly those things that are
alpha stuff, I'd like to see how this impacts what we already have, not
what we are adding.
> 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.
Exactly, I don't know either but I don't want to shake things around
twice.
> 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.
I'm not against having smaller cocoon jar files, also because we can
have Ant repackage them into one big one when we build a distribution.
> Any thoughts on this?
Before stating my vote I want to see a detailed action plan but I would
also suggest to wait for this until the cocoon blocks are designed.
Moreover, I can't really see how you can say that the Cocoon build
system is slow, but probably I'm missing your point entirely.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
