Return-Path: 
 <commons-dev-return-85703-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 13522 invoked from network); 6 Mar 2006 16:43:26 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 6 Mar 2006 16:43:26 -0000
Received: (qmail 82085 invoked by uid 500); 6 Mar 2006 16:43:55 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 81992 invoked by uid 500); 6 Mar 2006 16:43:54 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 81980 invoked by uid 99); 6 Mar 2006 16:43:54 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Mar 2006 08:43:54 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of rahul.akolkar@gmail.com
 designates 64.233.162.192 as permitted sender)
Received: from [64.233.162.192] (HELO zproxy.gmail.com) (64.233.162.192)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Mar 2006 08:43:54 -0800
Received: by zproxy.gmail.com with SMTP id x3so1258128nzd
        for <commons-dev@jakarta.apache.org>;
 Mon, 06 Mar 2006 08:43:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=E601tw8inWiryUJ4c2nx4s4BEmxfZKGIsLsbESOWYszALR1rrFptVyVJUp/xGVhj3u61ysx8YTbJO6uqBWG2iQhI2ZXrTcpK/vpu/GFJE4VAU2vNd9DGuOcw7YWLhnLY1XTSvblkY3vtJtgA/Iu6AsrgLl3a1rS4lqSwIYrR8GQ=
Received: by 10.36.251.29 with SMTP id y29mr632659nzh;
        Mon, 06 Mar 2006 08:43:31 -0800 (PST)
Received: by 10.36.60.10 with HTTP; Mon, 6 Mar 2006 08:43:31 -0800 (PST)
Message-ID: <ce1f2ea80603060843w219aee10l2a8129a76ab846a9@mail.gmail.com>
Date: Mon, 6 Mar 2006 11:43:31 -0500
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [all] Proposal: Jakarta Language Components
In-Reply-To: <440B44F9.90200@btopenworld.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <440B44F9.90200@btopenworld.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

On 3/5/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
<snip/>
>
> I hereby propose the creation of a new Jakarta entity named 'Jakarta
> Language Components'.
>
<snap/>
>
>
> For some, this may invoke an immediate negative reaction. But I'd ask
> you to pause and reflect a while. This change allows a new approach to
> commons to be tried - smaller and more focussed. The new group is large
> enough to not be inactive, yet small enough to be manageable. To succeed
> however, it will need to support of those developers who do commit to
> these components at present.
>
<snip/>

Makes sense, we've been talking about narrow-deep/shallow-broad for
quite a while (credit to you) and this is a similar take on the
situation. But I think this grouping is the easy part.

To the effect of what Hen says later in this thread, its the
narrow-deep bits that have been the "ugly ducklings", whereas it has
been proven sufficient number of times that both "categories" are
extremely useful (for example, think of the number of ASF projects
that use digester). Just as its said that Jakarta is multiple
communities based on what it has grown into organically, we must also
agree Commons has grown into a community that harbors both flavors of
components.

If this proposal means a departure from the "rest of Commons" of the
part of the community that is interesting only in JLC, then this is a
loss. While you (Stephen) may be inclined towards the shallow-broad
variety, the fact that the latest usecase for scxml comes out of your
slides is still invaluable, IMO. We have to address the future of
*all* of Commons in such proposals, I tend to feel they're a tad
incomplete otherwise.

-Rahul


> Stephen
>

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