ah, the load, the load! I can't take it anymore!!!! <action type="jump-of-cliff" entity="avalon"/>
AAAAAaaaaaa a a a a h!
:D:D Just kiddin' :D
LOL :)
Anyone know the album "cocoon crash" by K's Choice? Sounds a bit different :D
I have to be honest with you: I find the dependency on tons of small jars disturbing to say the least. I know it's probably possible to move from excalibur-cli to commons-cli or whatever, but I don't know how, nor, to be honest, I even dare to touch it. And this is just an example.
the alternative is to only depend on
http://www.apache.org/dist/avalon/framework/latest/ http://www.apache.org/dist/avalon/excalibur/latest/
until we release a new "excalibur-all". It's just going to take more time till the new "excalibur-all" is available.
I know Avalon Framework, but almost everything else looks mysterious and incredibly fragmented to my eyes.
heh. I get the opposite impression from cocoon :D. Working on it.
You may also want to drop your deps on instrument-manager (IMV, instrumentation management should be plugged into the container (ECM), and client code like cocoon shouldn't have to deal with it). Note this is just recommendations on personal title, no consensus within avalon (yet) about everything on that list.
Which is adding concerns over concerns.
also note there _may_ be consensus on those recommendations, I just haven't bothered to find out. And I really don't actually know cocoon well enough to make those recommendations (a better recommendation: listen to (or nag them for an opinion if they don't speak up :D) Berin, Leo, Nicola, Carsten, you know, all those guys who actually work on both cocoon and avalon).
If there's stuff missing from this list, it'd be good to know.
I think it is a good idea to get the gump descriptors for cocoon and avalon (further) in sync with reality so this information is machine-readable and auto-maintained :D
No shit. Another thing that looks mysterious to me is Gump so any help will be very appreciated.
gump has a steep learning curve and a high annoyance factor, but it does pay off.
suggestion: get Pier to mirror the gump installation on nagoya on one of his local machines (he's got tons of hardware, right?), making sure to get all the binary packages as well, then nag him till you get access to the machine, read http://jakarta.apache.org/gump/usage.html, and run it yourself. Play around with it.
Alternatively, don't mirror but start with a minimal profile (http://cvs.apache.org/viewcvs.cgi/jakarta-gump/minimal-workspace.xml) which you rename to $(machine-name}.xml, and follow the instructions at the url mentioned above. Add references to more and more projects, run gen.(sh|bat) everytime you add one, checkout missing modules and install missing packages. Read the data definition material (http://jakarta.apache.org/gump/overview.html) on the gump site.
Gump is basically a little bit of java with a little bit of ant and a massive amount of XSLT and shell scripting. Gump reads various xml files (most important ones the project definitions in http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/), then uses XSLT (see http://cvs.apache.org/viewcvs.cgi/jakarta-gump/stylesheet/bash.xsl for an example) to merge them all together and generate huge (> 5mb if you run a "full" gump) commandline scripts which checkout sources and call ant, while overriding the classpath.
Gump's implementation is 'a bit' of a hack if you asks me, but the xml format is good, as are the docs. It makes me think of something like a SOAP appserver written in PERL with a TCL-based frontend.
On a related note, I played around with splitting the cocoon core up (conceptually at least) into a core and some smaller bits, and it looks possible but the 'actual' core is distributed among many packages that don't look like they're the core, containing "non-core core" as well. Confused you there? Myself too. More later.
g'night,
- Leo
