cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] what cocoon is doing wrong
Date Tue, 25 Feb 2003 22:13:50 GMT

Stefano Mazzocchi wrote, On 25/02/2003 19.55:
> There are a few things that we are doing wrong. I'll make a dump of my 
> random thoughts about these in order to foster a discussion.
> 
> Building on sand
> ----------------
> 
> We developped a habit of building on sand.
> 
> 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.

I think so too. Especially about excalibur. IMHO there is no reason why 
we need to move Avalon components there. The community is here. Let's 
keep them here. Anyone that needs them can get them from this project.

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

Continuous integration. Have Gump work, and the changes will not affect 
much.

> I'm starting to think that the Cocoon dev team should create a policy
> 
>   +------------------------------------------------------+
>   | never commit code that depends on non-released stuff |
>   +------------------------------------------------------+

Or: code that depends on non-released stuff must have a vote from 
committers to be included.

> Another example: the Source stuff moved to Avalon.
> 
> Is it possible that things are marked as *deprecated* and even Cocoon 
> itself depends on deprecated stuff? sand on sand.

Yes, this is a problem. We need to finally make the deprecated stuff not 
needed by Cocoon, and set a policy in the build system (unit test like) 
that checks for @deprecated classes that are not in the deprecated dir.

> Huge library dependance
> -----------------------
> 
> Let's look at the list of libraries we depend on:
> 
> why do we depend on different 'concurrent' libraries?

Transition in Avalon.

> why do we have altRMI stuff over in /lib/optional when they are needed 
> by the instrumentation that is placed on /lib/core? wouldn't it be core 
> itself?

With blocks we should not need the optional dir, so the problem fixes 
itself.

> do we really have to depend on *THREE* different xpath libraries 
> (xalan,jxpath and jaxen)? 

Yes.

They do not do the same things. Also remember the dependncies of 
dependencies...

> can't we make an avalon component that 
> provides xpath querying services and work from there?

I find it faster and easier to depend on these three.
If you want to try... ;-)

> why do we need both 'excalibur-logger' and 'commons-logging'? didn't we 
> refactor the log?

? Commons logging was needed with POI and is with other Jakarta Commons 
libraries. excalibur-logger is for Cocoon usage. Dependncies of 
dependencies...

We are working on a logging.apache.org, but it will take some time.

> why we depend on cornerstone-excalibur-thread*?
> 
> 
> Scratchpad considered harmful
> -----------------------------
> 
> I proposed to remove the scratchpad and no consensus was reached. I try 
> again but this time harder: I think the scratchpad is harmful.
> 
> Reasons:
> 
> 1) for non-core stuff, alpha blocks will do just fine and will even keep 
> libraries out of the way.

I agree *only* if you put them in a separate dir. Test code with normal 
code is even more *harmful* than dead code.

> 2) if you want to try things around with core stuff, I *WANT* you to do 
> it on the head. It's called 'continous integration'. No, dude, I won't 
> make it easier for you, I want it to make it harder so that everybody 
> sees what you're doing and can improve on it.
> 
> I repeat my proposal to kill the scratchpad

Hmmm... how could we have done the flow without the scratchpad?
Do you really think that Schecoon could have been done in head?

Make the scratchpad-blocks dir, and that will automatically solve many 
of these problems and clear the scratchpad.

Let's KISS. Let's start with the obvious. Move the scratchpad into 
scratchpad-blocks and see what's left. We may be surprised.

> enough for now. i need food.

Foood!!! :-D

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message