You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leo Simons <le...@apache.org> on 2003/02/26 19:23:47 UTC
cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Stefano Mazzocchi wrote:
> Recently on avalon-dev I expressed my concerns about their habit of
> moving stuff around for elegance-sake, but I'm starting to think that
> Cocoon is abusing avalon and this places too much pressure on their
> shoulders.
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
>
> Example: the instrumentation. The Cocoon core is based on code that has
> never been released. So, Avalon has the right to move it around (and
> screw us). But I don't think it's *their* fault, it's entirely ours.
I don't really care who's to blame, there's just an issue needing
fixing...though I support the search for the right policy :D
If people that know both cocoon and avalon well can figure out what
stuff in avalon it is that cocoon _really_ needs atm, and we can figure
out what it takes to get that released, and then do it (already working
on it, all help welcome :D), that pretty much make the world happier :D.
Berin's list of a few days ago:
CLI
Collections
Concurrent
i18n
instrument
instrument-manager
instrument-manager-interfaces
IO
Logger
Monitor
Naming
Pool
SourceResolve
Store
XMLUtil
Cornerstone
Cornerstone-excalibur-thread
Cornerstone-excalibur-threadcontext
DataSource
AltRMI
AltRMI Registry
AltRMI Server (IMpl/Interfaces)
Component (AKA ECM)
(AltRMI is no longer part of avalon though; that's in incubator now)
Of this list, if it is possible and sensible to remove the cocoon deps on
cli,
collections,
concurrent,
IO,
"all of cornerstone" (as opposed to one or two specific blocks) and
AltRMI,
I recommend y'all try. 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.
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
cheers,
- Leo
PS: please CC dev@avalon on the avalon deps in cocoon; there's certainly
willingness to help out with this stuff over @ avalon but I can't keep
up with your massive amount of traffic :D
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Stefano Mazzocchi wrote:
>
> (AltRMI is no longer part of avalon though; that's in incubator now)
>
> Of this list, if it is possible and sensible to remove the cocoon deps on
>
> cli,
Easy enough.
> collections,
> concurrent,
Both done--all that is required is a new ECM
> IO,
I don't think Cocoon is using any of these classes, is it?
> "all of cornerstone" (as opposed to one or two specific blocks) and
Cornerstone can definitely be removed. I have a patch, but I want to
get some oppinions on it before committing the change.
> AltRMI,
This is dependend on Instrument--which the Avalon team needs to take
care of.
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Leo Simons wrote:
> which package are you referring to,
IIRC org.apache.xml.utils.PrefixResolver
> and why is it worrying it depends on Xalan?
I'd like to rip out the Xalan jar, put in Saxon, and start
Cocoon without being surprised by a ClassDefNotFound exception.
J.Pietschmann
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Leo Simons <le...@apache.org>.
J.Pietschmann wrote:
> Leo Simons wrote:
>
>> the alternative is to only depend on
>
>> http://www.apache.org/dist/avalon/excalibur/latest/
>
> What worries me is that excalibur depends on a class
> distributed with Xalan.
which package are you referring to, and why is it worrying it depends on
Xalan? Something wrong with relying on Xalan?
cheers,
- Leo
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Leo Simons wrote:
> the alternative is to only depend on
...
> http://www.apache.org/dist/avalon/excalibur/latest/
What worries me is that excalibur depends on a class
distributed with Xalan.
J.Pietschmann
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> 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.
Those are the links to the currently released Avalon stuff. There is
also the http://www.apache.org/dist/avalon/logkit/latest/ which
currently points to LogKit 1.2.
> 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]
Only 15" ? Those 17" laptops look mighty tasty to me ;P
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
> I'm slowly working at finding out the internal dependencies of Cocoon
> core myself. Let's not step on each other toes.
I wouldn't worry 'bout that. Me not cocoon committer, nor intending to
become one :D
cheers,
- Leo
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Stefano Mazzocchi <st...@apache.org>.
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 <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
>> 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
Re: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> Stefano Mazzocchi wrote:
>
>> Recently on avalon-dev I expressed my concerns about their habit of
>> moving stuff around for elegance-sake, but I'm starting to think that
>> Cocoon is abusing avalon and this places too much pressure on their
>> shoulders.
>
>
> 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 :)
>>
>> Example: the instrumentation. The Cocoon core is based on code that
>> has never been released. So, Avalon has the right to move it around
>> (and screw us). But I don't think it's *their* fault, it's entirely ours.
>
>
> I don't really care who's to blame, there's just an issue needing
> fixing...though I support the search for the right policy :D
Great.
> If people that know both cocoon and avalon well can figure out what
> stuff in avalon it is that cocoon _really_ needs atm, and we can figure
> out what it takes to get that released, and then do it (already working
> on it, all help welcome :D), that pretty much make the world happier :D.
> Berin's list of a few days ago:
>
> CLI
> Collections
> Concurrent
> i18n
> instrument
> instrument-manager
> instrument-manager-interfaces
> IO
> Logger
> Monitor
> Naming
> Pool
> SourceResolve
> Store
> XMLUtil
> Cornerstone
> Cornerstone-excalibur-thread
> Cornerstone-excalibur-threadcontext
> DataSource
> AltRMI
> AltRMI Registry
> AltRMI Server (IMpl/Interfaces)
> Component (AKA ECM)
>
> (AltRMI is no longer part of avalon though; that's in incubator now)
>
> Of this list, if it is possible and sensible to remove the cocoon deps on
>
> cli,
> collections,
> concurrent,
> IO,
> "all of cornerstone" (as opposed to one or two specific blocks) and
> AltRMI,
>
> I recommend y'all try.
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.
I know Avalon Framework, but almost everything else looks mysterious and
incredibly fragmented to my eyes.
I'm not asking for migration docs or anything, I'm just stating that I
find it irritating to have so many dependencies and not even have a way
to find out what depends on what.
> 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.
> 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.
> cheers,
>
> - Leo
>
> PS: please CC dev@avalon on the avalon deps in cocoon; there's certainly
> willingness to help out with this stuff over @ avalon but I can't keep
> up with your massive amount of traffic :D
ok
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
RE: cocoon deps on avalon (Re: [RT] what cocoon is doing wrong)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Stefano Mazzocchi wrote:
> Recently on avalon-dev I expressed my concerns about their habit of
> moving stuff around for elegance-sake, but I'm starting to think that
> Cocoon is abusing avalon and this places too much pressure on their
> shoulders.
>
> Example: the instrumentation. The Cocoon core is based on code that
has
> never been released. So, Avalon has the right to move it around (and
> screw us). But I don't think it's *their* fault, it's entirely ours.
I think there's enough blame for both projects. Cocoon has built on
unreleased code, and Avalon has had a terrible track record of releasing
stuff...
I think the meaning behind your comments on dev@avalon were justified,
although I think the situation is not getting worse, it is getting
better.
/LS