cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [PROPOSAL] splitting Cocoon
Date Fri, 12 Apr 2002 05:10:45 GMT
On Thu, 11 Apr 2002, Ovidiu Predescu wrote:

> On Thu, 11 Apr 2002 13:49:34 +0200, Stefano Mazzocchi <> wrote:
> > 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
> > > "./ -Dinclude.webapp.libs=true webapp" from scratch in Cocoon
> > > takes 2 minutes and 10 seconds. In Schecoon a "./ 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)
> Poor you, I also have a Pentium II 400 laptop, so I know how painful
> it is :-(
> I usually use Emacs JDE to compile the Java files directly in the
> build area. I have Emacs setup to automatically copy resource files in
> the build directory each time I modify them in the source
> directory. I've setup Tomcat to load the webapp from the
> build/cocoon/webapp directory, to avoid having to copy the war file. I
> think I do pretty much all I can to minimize the need to run
> But every now and then, when I modify resource files, like .xconf, it
> requires me to run a "build webapp". Each time I do this, I need to
> wait 15 seconds or more until right before the "webapp" target. This
> is a long time for me, I don't want to wait this much.
> > > 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.
> OK, this makes sense.
> > > 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.
> I was looking at the current CVS, and here is how I see the directory
> structured:
> core/
>     - all the classes in org.apache.cocoon
>     - all of the classloader/, environment/, matching/, selection/,
>     servlet/, sitemap/, util/ and xml/ directories
>     - portions of the remaining directories, excluding browser/,
>     crawler/, deli/, hsqldb/, jsp/ and so on, which are not core to
>     the Cocoon engine. Only the abstract interfaces and classes which
>     are relevant to the core Cocoon will remain here.
> All the non-essential core components and the functionality which
> builds on top of the core should appear in different directories.
> For example, we'd have hsql/, crawler/, deli/, hsqldb/ and so on,
> appear as sibling directories of the core/ directory. Each of these
> directories contains the code, documentation, tests, build file,
> everything they need.
> To avoid creating too many directories right under the top-level
> directory, we can group things in functionality, like database/,
> devices/, markup/, etc. Inside these directories we can have
> directories, each dealing with support for a particular piece. For
> example the devices/ directory would contain the browser/ and deli/
> directories.
> > > 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.
> Do we plan to restructure the current Cocoon so that we'll have
> portions of it implemented as Cocoon blocks?

I think it will be a need to restructure it for visibility and easier
build process.

> If so, probably it
> doesn't make sense to change things at this point.


> But I would love to
> clean up the current code, there are just too many things that get
> added in cocoon.jar.

Well, go for it. But I don't see how that would save you some time in
the build process.

> > > 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.
> We can also have a distribution containing the smaller jar files, so
> that various applications can pick up only the jar files they
> need. For example an application could use only cocoon-core.jar,
> cocoon-flow.jar, cocoon-velocity.jar to build simple things, with no
> SVG, database access, search engine, and so on.

It would make sense to split Cocoon into pieces like you've mentioned.
This could also be because they are becoming a Cocoon Block.

> I hope Cocoon blocks would make picking up individual jar files
> obsolete. So that instead of having the the basic block a jar file, we
> would deal with .cob files which are self contained.
> So I'm definitely waiting to see Cocoon blocks coming soon ;-)
> > > 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.
> Yes, the more I think about it, the more it makes sense to wait until
> then.
> What is the status of Cocoon blocks as of today? Can you give us an
> update?

IIRC we talked about the "contract" of a CB and how much validation
should be applied to an implementation of such a contract.

> > 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.
> As I said, I want things to be available instantly. Waiting 20 seconds
> for a build is 19 seconds too many.

I would be very supprised if we get down to nearly 1 second.


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

View raw message