Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200204112118.g3BLI8F18365@orion.rgv.hp.com>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Stefano Mazzocchi <stefano@apache.org>
Cc: cocoon-dev@xml.apache.org
Subject: Re: [PROPOSAL] splitting Cocoon 
In-Reply-To: Your message of "Thu, 11 Apr 2002 13:49:34 +0200."
             <3CB5784E.D1C62693@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Apr 2002 14:18:08 -0700
Sender: ovidiu@orion.rgv.hp.com

On Thu, 11 Apr 2002 13:49:34 +0200, Stefano Mazzocchi <stefano@apache.org> 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
> > "./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)

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 build.sh.

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? 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.

> > 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.

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?

> 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.

Cheers,
Ovidiu

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