cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] what cocoon is doing wrong
Date Wed, 26 Feb 2003 11:53:56 GMT
Carsten Ziegeler wrote:
> 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.

I'm doing refactoring because I want to release, not the opposite.

Removing dependencies will improve our ability to REaO (Release Early 
and Often)

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

Ok, that's good enough.

Also, I would add that we should not put code in HEAD that depends on a 
unreleased software that *NEVER* made a 1.0 release. This will keep the 
contracts shaped up.

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

Moving the SourceFactory to Avalon made a mess. This is what I'm mostly 
concerned at the moment. What is the status of this?

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

I asked a vote for this and the lazy consensus was that libraries that 
depend on *ONE* block will go into the block/lib directory, the 
libraries shared by blocks will remain in /lib/optional.

Did I overlook something?

Do others believe that I acted on my personal behalf against community 

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message