cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: New Build Report
Date Mon, 24 Feb 2003 20:33:02 GMT
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 <project/> 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 

Looking at things the other way around, I would expect that "<depend 
project="maybeupload"/>" refers to only a small part of cocoon, and that 
"<depend project="junit"/>" 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


- Leo

View raw message