Return-Path: 
 <commons-dev-return-186-apmail-xml-commons-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-commons-dev-archive@xml.apache.org
Received: (qmail 52216 invoked by uid 500); 18 Nov 2002 23:39:29 -0000
Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:commons-dev-help@xml.apache.org>
list-unsubscribe: <mailto:commons-dev-unsubscribe@xml.apache.org>
list-post: <mailto:commons-dev@xml.apache.org>
Delivered-To: mailing list commons-dev@xml.apache.org
Received: (qmail 52207 invoked from network); 18 Nov 2002 23:39:29 -0000
Received: from web13113.mail.yahoo.com (216.136.174.181)
  by daedalus.apache.org with SMTP; 18 Nov 2002 23:39:29 -0000
Message-ID: <20021118233936.76587.qmail@web13113.mail.yahoo.com>
Received: from [24.120.61.2] by web13113.mail.yahoo.com via HTTP;
 Mon, 18 Nov 2002 15:39:36 PST
Date: Mon, 18 Nov 2002 15:39:36 -0800 (PST)
From: Shane Curcuru <shane_curcuru@yahoo.com>
Subject: [PROPOSAL] xml-commons project organization: several subprojects
To: commons-dev@xml.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Greetings from ApacheCon!

I've been mulling a number of things about xml-commons for a while and
figured I'd better let people know about them - sharing ideas can be a
good thing!  (Thanks to ~crossley for prodding me to do this by
checking in a forrestized seed site which I'll beef up soon with more
real docs).

I propose that we change how xml-commons releases distributions. 
Originally I thought we should have big monolithic
xml-commons-version.zip files and shipped a couple of betas that way. 
But it's obvious now that many people will want just part of
xml-commons, and we should treat it that way.

---- 1. Distribution Proposal ----
Each xml-commons component will ship it's own individual .zip/.tar.gz
files, much like the recent xml-commons-resolver-1.0 release (and hence
an xml-commons-external=xml-apis.jar, and xml-commons-which=which.jar).
 I think this is a pretty obvious good thing.

Any comments?


---- 2. Documentation Proposal ----
I'd like to figure out a way that each project can manage and ship it's
own full doc set using xml-forrest, plus have an extra index page that
describes the whole xml-commons project.  I think it's important that
the actual distributions have the right doc set inside of them for
external users who may be picking these tools up from other sources or
other reasons.  I'm hoping this is fairly easy to do with static
forrest generation.

Discussion?  Forrest suggestions?


---- 3. Code proposal ----
Someone recently made a request that they wanted an easier way to just
check out the code needed only for resolver, and not the rest of the
repository, which is not easy to do currently.  I'm wondering if at
some point we should consider actually restructuring the cvs tree to
make this simpler to do or not.  (Is there an easy way to setup modules
in CVS that would let us do this without moving directories?) 
Unfortunately when we started, we put the /external directory under the
/java directory (and there's a bunch of files in there, which someone
might complain about having to cvs update if they only wanted just
resolver or which)

Comments?  


Also, as an aside: any comments about Which?  Admittedly I haven't
updated it to recent ant/xerces/xalan releases, but I was wondering if
many other folks found it useful yet or not.  (Note: better doc will be
coming soon!)

=====
- Shane

<eof .sig="'When I use a word,' Humpty Dumpty said, 
in a very scornful tone, 'it means just what I 
choose it to mean - neither more nor less'"
"Oohayu oyod?!"=gis. />

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com