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 o.a.c.language.programming.javascript.
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
cheers,
- Leo
