Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Sender: vt@freehold.crocodile.org
Message-ID: <381F79F8.B7EDF3B@freehold.crocodile.org>
Date: Tue, 02 Nov 1999 17:55:36 -0600
From: Vadim Tkachenko <vt@freehold.crocodile.org>
Organization: VT? Organized?
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [Vote] Package structure, code sharing and project proposal
References: <381EFB48.69169CB@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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