cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Date Wed, 26 Feb 2003 21:12:22 GMT
Leo Simons wrote:

>> 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.

Hmmm, I want to see things stable inside the HEAD *before* attempting to 
go down this path. Call me superconservative, but there are already too 
many things we depend on and we can rarely control.

>> 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.

I know, me too. Avalon appears fragmented and Cocoon appears monolithic. 
Hopefully we'll converge toward a common mindset.

>>> 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.

My problem so far has been working on a 42 Kb modem connection until 
last year, then shit happened and that ADSL connection was gone, then I 
travelled and only in the past few months I could have a decent 
connection. I think the increase in my CVS commits shows this pretty 
evidently.

But anyway Gump was simply too big, my machine too small, my connection 
too slow, my geographical location too moving. I'm working to improve 
all these, even if it will take time. For now, I can steal my dad's 
office's ADSL, pretending to be working for him at creating his 
company's web site :)

> 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.

I have an account on nagoya myself.

> 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.

Hmmm, I have 500Mb left on my harddisk :/ but I'll see what I can do. [I 
know, I know, I should buy a new laptop, but Apple is delaying shipping 
the titaniums... I smell hardware upgrade on the 15" line]

> 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.

Yes, I know how massively hacky Gump is.

I'll try to work something out.

> 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.

LOL, I have to let Sam know this. :)

> 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.

I'm slowly working at finding out the internal dependencies of Cocoon 
core myself. Let's not step on each other toes.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



Mime
View raw message