[Vote] Package structure, code sharing and project proposal

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

People,

the class-naming pattern introduced by the Java Language specification
is great because allows a cleaned and coherent positioning of files and
classes. 

The problem is that if one domain hosts more than a single project (like
Apache does), there must be a common "contract" on shared files and
classes.

Also, there is the need for a more advanced revisioning system (thru a
better/wiser use of CVS) that allows modules to share parts of other
modules (via symlinks or directly thru CVS features, sorry I'm no CVS
guru)

It is clear that there are particular things that every apache project
needs: configurations, utilities, recycling, classloaders, logging,
concurrency, etc...

At the end, here is my proposal for a global contract for package
structures.

A global votation should settle these patterns. (Brian, is the ASF board
required to rule on this? or should all the java-related projects agree
first and then submit something for final approuval?)

-------> Cut Here <---------------

1) the package root is

    org.apache

and is the base of all the ASF classes, today and in the future. Future
code donations to the ASF will have to be moved under this package name.

2) each independent project (the PMC boards or general consensus will
decide if this applies) will follow the package

    org.apache.<project_name>

The use of complete URI is avoided since excessively verbose (i.e.
org.apache.tomcat instead of org.apache.jakarta.tomcat)

3) shared classes and interfaces will be placed in 

   org.apache.[xxx]    [NOTE: xxx needs to be voted]

A PMC or similar board will coordinate the inclusion, update, bugfix and
evolution of these classes since they build strong "contract" that are
used by all the other projects and should be carefully changed to avoid
impact on the other projects.

Possible names for [xxx]

 a) empty    -> org.apache
 b) "java"   -> org.apache.java (as in JServ)
 c) "share"  -> org.apache.share
 d) "util"   -> org.apache.util
 e) "common" -> org.apache.common
 f) ??? (any suggestion welcome!)

4) the subpackage structure will be

  org.apache.[xxx] ................ general design pattern exposures

these classes will be component model used for componentized frameworks
(such as Avalon, Cocoon, Turbine, Tomcat). Basic interfaces that expose
common design patterns, such as Component, Service, Composer, Version,
etc... 

  org.apache.[xxx].config ......... configuration 

used for configuration issues and created with the merging of the JServ,
Tomcat, Cocoon and Avalon configuration classes. Abstracted on file
syntax (XML and java.properties) and tree structured format.

  org.apache.[xxx].util ........... utility classes
  org.apache.[xxx].recycle ........ recycling classes (moved from
org.apache.java.recycle)
  org.apache.[xxx].lang ........... java.lang addictions (moved from
org.apache.java.lang)

  org.apache.[xxx].?? ............. anything that is general enough to
be included 

5) Issues to resolve are:

a) general consensus and strong contract: all projects must agree on the
general consensus or the share classes will provide more harm than good.

b) creation of a project to control the shared code with own CVS module.

c) integration with the other projects with stronger CVS and
distribution link (separate jar files to avoid code duplication in
classpath).

d) creation of the board to control the project and a public mail list
for discussion.

e) relation to the Java API and other shared libraries: should this
project be targetted to create a server-side utility API for external
projects as well? Sort of CPAN for general utility classes?

-----------------------------

Please, since most java.apache developers are non subscribed to the PCM
internal lists, CC to the public mail lists for public discussion, sorry
for the crossposting but there is no public place for all the Apache
java development. (the shared library project mail list should become
the one)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche

Re: [Vote] Package structure, code sharing and project proposal

[Vadim Tkachenko <vt...@freehold.crocodile.org>]

Stefano Mazzocchi wrote:

> 3) shared classes and interfaces will be placed in
> 
>    org.apache.[xxx]    [NOTE: xxx needs to be voted]
> 
> A PMC or similar board will coordinate the inclusion, update, bugfix and
> evolution of these classes since they build strong "contract" that are
> used by all the other projects and should be carefully changed to avoid
> impact on the other projects.
> 
> Possible names for [xxx]
> 
>  a) empty    -> org.apache

-1, because of the cluttering and security implications. If the shared
pieces of code will have to be able to execute priviledged actions,
their code base must be insulated.

>  c) "share"  -> org.apache.share

+1

> 5) Issues to resolve are:
> 
> a) general consensus and strong contract: all projects must agree on the
> general consensus or the share classes will provide more harm than good.

Plus, I'd suggest to package the shared classes into an independent
project and use its components (to be addressed as
org.apache.[xxx].<component>) with --with-COMPONENT configure option,
where applicable - not every project needs all of those, but the
separation between different shared entities is quite clear.

> b) creation of a project to control the shared code with own CVS module.

+1, oops, this basically says what I've just typed

> c) integration with the other projects with stronger CVS and
> distribution link (separate jar files to avoid code duplication in
> classpath).

+1, though we probably see this differently

> d) creation of the board to control the project and a public mail list
> for discussion.
> 
> e) relation to the Java API and other shared libraries: should this
> project be targetted to create a server-side utility API for external
> projects as well? Sort of CPAN for general utility classes?

+1, long overdue

> Stefano Mazzocchi

--vt

Re: [Vote] Package structure, code sharing and project proposal

[James Duncan Davidson <ja...@eng.sun.com>]

> 2) each independent project (the PMC boards or general consensus will
> decide if this applies) will follow the package
>
>     org.apache.<project_name>

+1 -- note this is what we do in Jakarta land already (org.apache.tomcat,
etc).

>  c) "share"  -> org.apache.share

+1

> a) general consensus and strong contract: all projects must agree on the
> general consensus or the share classes will provide more harm than good.
>
> b) creation of a project to control the shared code with own CVS module.
>
> c) integration with the other projects with stronger CVS and
> distribution link (separate jar files to avoid code duplication in
> classpath).
>
> d) creation of the board to control the project and a public mail list
> for discussion.
>
> e) relation to the Java API and other shared libraries: should this
> project be targetted to create a server-side utility API for external
> projects as well? Sort of CPAN for general utility classes?

I know that Brian probably wants to pause on considering this until we get a
few other fires down (and I concur! :) -- but this is an issue that we have
to deal with at some point in the future.

RE: [Vote] Package structure, code sharing and project proposal

[David Duddleston <da...@i2a.com>]

> -----Original Message-----
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> Sent: Wednesday, November 03, 1999 11:29 AM
> To: tomcat-dev@jakarta.apache.org
> Cc: Java Apache; Jakarta PMC; pmc@xml.apache.org
> Subject: Re: [Vote] Package structure, code sharing and project proposal
>
>
> Stefano Mazzocchi wrote:
> > e) relation to the Java API and other shared libraries: should this
> > project be targetted to create a server-side utility API for external
> > projects as well? Sort of CPAN for general utility classes?
>
> I'm going to keep saying yes to this until it happens!

Same

+1

I believe some of the services for Turbine could fall into the library code
section along with other code being developed. Stefano... keep pushing.

I'm all for library code.

-david dudleston

Re: [Vote] Package structure, code sharing and project proposal

[Ben Laurie <be...@algroup.co.uk>]

Stefano Mazzocchi wrote:
> e) relation to the Java API and other shared libraries: should this
> project be targetted to create a server-side utility API for external
> projects as well? Sort of CPAN for general utility classes?

I'm going to keep saying yes to this until it happens!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi