xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [Vote] Package structure, code sharing and project proposal
Date Tue, 02 Nov 1999 14:55:04 GMT

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

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

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

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

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


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


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,

  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.[xxx].lang ........... java.lang addictions (moved from

  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

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.
<stefano@apache.org>                             Friedrich Nietzsche

To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


View raw message