cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Cocoon/Avalon Synchronizing
Date Tue, 13 Jun 2000 12:41:06 GMT
Stefano Mazzocchi wrote:

> Berin Loritsch wrote:
> >
> > In my marveling of the architecture of Cocoon, I was told that it was
> > based
> > on Avalon--and that we would eventually want to put the Avalon jars in
> > the
> > /lib directory.  Upon further investigation, the two projects share some
> > of
> > the same code but have them in different packages.  In order to
> > facilitate the
> > migration to Avalon code, I propose to have someone create the directory
> >
> > structure for and populate it with copies of the
> > files
> > in org.apache.arch (except for org.apache.arch.config).
> -1, we should keep C2 intact until we all agree on how the Avalon
> packages should be structured. And this must be done on the Avalon mail
> list. For now, it doesn't hurt to leave them here.

Problem is Federico is pretty convinced they should be in the area.  Apache James is built ground up on Avalon,
and is close to or at a version 1 release.  I'm not saying that those classes
should be marked 'final', but they should be the same.  Without a package
migration--and what I've proposed will keep it all working as we migrate--
then we will never be able to incorporate ApacheJava.jar and
AvalonInterfaces.jar (we won't need Avalon.jar until we are ready to integrate

with it's Logging/etc.).

I am of the mindset that I want to start working on stuff, but this stupid
package issue is hindering me.  I was planning on taking the responsibility
to make sure that the classes in all three locations become synchronized,
yet still work.  To me, that is the single important issue on this thread.

I will do my part to help in this endeavor, but I'm not going to be in the
midst of in-fighting.  I've heard response from Federico, he is happy that
there is interest in the project beyond him, and he gave me his reasoning
for the current package name.  It's all in the Avalon list archives.  Looking
at the CVS history, the Avalon move to was a little
over 4 weeks ago.

I am +1 on making the same.  I also expressed to Federico, that the resting
place for this things--no matter where they are--should be finalized.  I
they are where he wants them.

> > That way, I can start migrating the Cocoon base to use the official
> > package
> > locations.  This will facilitate easier maintainability by sharing the
> > same
> > codebase.  The only thing is it would be emensely more useful to include
> >
> > the JavaDocs for the base architectural package even though it is part
> > of
> > another package.
> Yes, but given those interfaces cannot be considered final, it would be
> a waste of time.

I doubt it is a waste of time.  If nothing else, just beefing up the class
description is important.  Every method of every class should at least
have the following information:
Assumptions on input. (pre-conditions)
Expected outcome of operation (post-conditions)
Constants used (invariants)

All good parts of a contractual agreement are incorporated in that list.
This must be done for the Components themselves if for nothing else.

> I suggest we work on the Avalon mail list to finalize it so that
> everyone is happy, then we place the avalon.jar in ./lib, update C2 code
> and release control of them to the avalon project.

In order to do that, we need to use code from C2.  It would make it emensely
easier to synchronize the development if I didn't have to worry about the
package names and such.

On top of that, we would be able to make Avalon finalized that much quicker
if we had all the foundational stuff in the ApacheJava.jar library (where it
is located in the Avalon framework), and if anyone needed to extend or modify
those classes, they do it through the Avalon project.  Otherwise we are
upstream without a paddle.

View raw message