Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 33293 invoked by uid 500); 24 Feb 2003 20:31:38 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 33278 invoked from network); 24 Feb 2003 20:31:37 -0000 Received: from main.gmane.org (80.91.224.249) by daedalus.apache.org with SMTP; 24 Feb 2003 20:31:37 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18nPG5-0000SY-00 for ; Mon, 24 Feb 2003 21:31:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: cocoon-dev@xml.apache.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18nPG4-0000SN-00 for ; Mon, 24 Feb 2003 21:31:28 +0100 From: Leo Simons Subject: Re: New Build Report Date: Mon, 24 Feb 2003 21:33:02 +0100 Lines: 70 Message-ID: References: <3E5A6775.3090305@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en In-Reply-To: <3E5A6775.3090305@apache.org> Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: >> ant distclean; ant webapp > > Ah, didn't know that. I've just fixed it. Try again. it woiks! > Yes, help will be great, but only after the build is not shaky. k. You got my e-mail :D PS: ulterior motive is wanting to push continous integration to the next level and see if I can get "the latest cvs of everything" genning the avalon website, as a proof-of-apache-wide-backwards-compatibility-watching. >> on a related note, now that I finally was able to build cocoon myself, >> I'll look at getting it running in gump again. On first glance the >> gump xml-cocoon2 project looks like it is a bit big to serve as "unit >> of integration". Have you tried splitting that up yet? > > What do you mean? gump being a continous integration tool, a is its basic "unit". My (limited) experience with continuous integration shows it is beneficial to have relatively small chunks of code as a unit, ie it's beneficial to split the 1.2mb cocoon jar into ten units or so as far as integration is concerned. That way, it is way easier to isolate where a build breaks. In fact, gump is also useful in finding (automatically preventing) circular deps. Like we had with avalon last week where altrmi depended on some part of cornerstone, which depended on utility code in avalon-excalibur, which depended on other utility code, which depended on altrmi. In tools like maven the dependency management is on a unit-is-jar basis. >> results in a massive classpath by the time the "core" is compiled. >> Does anyone know how much of the stuff put into the classpath is >> needed by the core? > > Unfortunately, all of it. hmm. There is no "core" in the cocoon core? from a quick glance at the code, it seems like for example org.apache.cocoon.i18n could be seperated out into an independent xml-cocoon-i18n target that depends only on avalon-framework and xpath. I would expect similar things to be true for o.a.c.util, and for stuff which looks like optional "add-ons", like o.a.c.language.programming.javascript. Looking at things the other way around, I would expect that "" refers to only a small part of cocoon, and that "" is isolated into a seperate tree alltogether. I guess I don't have to preach SoC around here -- It's beneficial to have your SoC applied to GUMP, too. That way, 95% of GUMP can build even when (for example) "deli" fails to build. There's hundreds of examples I can give this way. Simply put, o.a.c.generation doesn't depend on excalibur-logger, nor does o.a.c.serializer, so you should tell gump that. that's what I mean, I guess :D cheers, - Leo