Cocoon/Avalon Synchronizing

[Berin Loritsch <bl...@infoplanning.com>]

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 org.apache.java.lang and populate it with copies of the
files
in org.apache.arch (except for org.apache.arch.config).

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.

Re: Cocoon/Avalon Synchronizing

[Berin Loritsch <bl...@infoplanning.com>]

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 org.apache.java.lang 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
org.apache.java.lang 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 org.apache.java.lang 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
beleive
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
heading
upstream without a paddle.

Re: Cocoon/Avalon Synchronizing

[Stefano Mazzocchi <st...@apache.org>]

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 org.apache.java.lang 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.
 
> 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 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------