On Thu, 11 Apr 2002, Ovidiu Predescu wrote: > On Thu, 11 Apr 2002 13:49:34 +0200, Stefano Mazzocchi <[EMAIL PROTECTED]> 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?
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. Agreed. > 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. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
