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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------