cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] what cocoon is doing wrong
Date Wed, 26 Feb 2003 07:01:44 GMT

Stefano Mazzocchi wrote:
> 
> 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.
> 
Ah, it's time again to write an email that is larger than four lines. Hmpf.
Now, I think the problems you mention have all the same source
that I discribed in two emails last year (about our community being
healthy), but until today noone even commented my emails. So, it will be
interesting to see what this RT will do.
I would like to a add one more point: Most of us do not care about
releasing new versions. We *must* come back to release often - release
early. But each time, we try to get a new version out, someone comes
up and says: Wait XYZ is not finished/working/discussed right now,
we should first get this working. Or even worse, someone starts something
and leaves it in an uncompleted state, so others have to clean it up.

Now, to your points:

>    | never commit code that depends on non-released stuff |
>
I really would agree to this policy, if it is possible to follow. Now, in
theory that sounds really great and easy, but in practice it's near to
impossible. Think of the problems for example we had months/years
ago with severe bugs in Xalan or Xerces. We had to use the latest
CVS in order to get Cocoon running as the released stuff was not
working.
And what does released mean? One could argue that an alpha version
is a released version ;) 
I would like to relax the policy a little bit to:
Never release a stable version that depends on non-released stuff (where
released version has to be at least stable in API).

> 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.
> 
This is of course not optimal, but IMHO unavoidable - we (and others
as well) make sometimes mistakes in the design or concepts that have
to be cleaned-up in order to not create a mess. So, things have to
be deprecated and replaced by newer/cleaner solutions. As far as I 
know, Cocoon does not depend on deprecated stuff. There are only
some classes in the core that are now deprecated. Or am I wrong?


> Huge library dependance
> -----------------------
> 
It would be easy that Cocoon by itself depends only on some libraries,
but these libraries rely on others etc. So it's, again in practice, near
to impossible to remove the reference to two or three xpath or logging
apis unless you can achieve that all other projects use the avalon 
(or log4j or...) etc.
Months ago we agreed/voted that we put *all* jars in the main lib
directory and do not have separate lib directories for each block.
This was agreed on because if two blocks require the same jar, this
jar would be otherwise two times in our repo. Now, some days ago 
someone changed this...
So, actually this is another point, sometimes even if we as a community
agree on something - someone does not know/care about this decission
and is doing what he things is best.

And now back to bug-fixing...

Carsten

Mime
View raw message