You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/03/07 22:26:15 UTC

[all] Rest of commons

Rahul Akolkar wrote:
> 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.

You asked about the 'rest of commons'. But I don't want to dictate, I 
really don't. I'd prefer that those who are active in these areas made a 
couple more groups from the remainder of commons.

But, as some people like an example, I'll post one. But its an example. 
Remember however, that everyone will be working on Jakarta components, 
its just that some will be in the commons package structure.

- Language - Enhancing Java SE
lang, collections, io, primitives, beanutils, codec, id, cli
+oro, +regexp

- Enterprise - Enhancing Java EE
(Expertise in Java EE spec issues, classloader issues)
logging, email, modeler, launcher, daemon, dbutils, dbcp, pool, el, 
transaction, fileupload, discovery
+taglibs
(formerly Jakarta Web Components)

- Network - Network protocols, Http, Ftp, ...
(Expertise in protocols)
net
+httpclient
(formerly Jakarta Http Components)

- Application - Reusable modules
validator, chain, configuration, betwixt, digester, jxpath, jelly, vfs, 
math, jexl, attributes
+bcel, +bsf

Note that POI, Velocity, Hivemind and Turbine are not included as they 
may have enough community of their own.

I REALLY DIDN'T WANT TO WRITE THIS. I'm not that attached to these names 
or groups. Whether you like it or loath it isn't really the point of 
this thread. The point is to indicate how many groups I would aim for 
(3-5) and one example setup. (The best approach may be to let Jakarta 
Language Components setup and see if it works!)

Its up to those involved in these projects to choose their next steps. 
And ideally, to change a mindset to working on Jakarta components not 
commons components.

Stephen

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


Re: [all] Rest of commons

Posted by Henri Yandell <fl...@gmail.com>.
On 3/7/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Rahul Akolkar wrote:
> > 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.
>
> You asked about the 'rest of commons'. But I don't want to dictate, I
> really don't. I'd prefer that those who are active in these areas made a
> couple more groups from the remainder of commons.
>
> But, as some people like an example, I'll post one. But its an example.
> Remember however, that everyone will be working on Jakarta components,
> its just that some will be in the commons package structure.
>
> - Language - Enhancing Java SE
> lang, collections, io, primitives, beanutils, codec, id, cli
> +oro, +regexp
>
> - Enterprise - Enhancing Java EE
> (Expertise in Java EE spec issues, classloader issues)
> logging, email, modeler, launcher, daemon, dbutils, dbcp, pool, el,
> transaction, fileupload, discovery
> +taglibs
> (formerly Jakarta Web Components)
>
> - Network - Network protocols, Http, Ftp, ...
> (Expertise in protocols)
> net
> +httpclient
> (formerly Jakarta Http Components)
>
> - Application - Reusable modules
> validator, chain, configuration, betwixt, digester, jxpath, jelly, vfs,
> math, jexl, attributes
> +bcel, +bsf
>
> Note that POI, Velocity, Hivemind and Turbine are not included as they
> may have enough community of their own.

They don't. Well, Hivemind does I think, the rest are only different
from bcel/bsf in terms of conceived size.

>
> I REALLY DIDN'T WANT TO WRITE THIS. I'm not that attached to these names
> or groups. Whether you like it or loath it isn't really the point of
> this thread. The point is to indicate how many groups I would aim for
> (3-5) and one example setup. (The best approach may be to let Jakarta
> Language Components setup and see if it works!)

Someone had to write it, and I suspect if I do any more of these
emails that I'll get lynched :)

3-5 seems good (I'd go with the "human's can only handle up to 7 choices" bit).

> Its up to those involved in these projects to choose their next steps.
> And ideally, to change a mindset to working on Jakarta components not
> commons components.

Let's get this on general@jakarta. I've some suggestions for other
groupings, but should wait til we get it in front of all of Jakarta.

Hen

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


Re: [all] Rest of commons

Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/7/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Rahul Akolkar wrote:
<snip/>
> >
> > 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.
>
> You asked about the 'rest of commons'. But I don't want to dictate, I
> really don't. I'd prefer that those who are active in these areas made a
> couple more groups from the remainder of commons.
>
<snap/>

Stephen -

I appreciate you taking a stab at this. While I did use an example
that had your "API style preference" in it, it wasn't my intent to put
you (or any single person) on the spot at all. As I mentioned, I
believe *we* need to think about Commons/Jakarta as a whole -- and JLC
isn't declaring victory by itself. Lets hope this thread (and the
others already on general@) spawn the beginnings of good things for
roC.

Again, thank you.
-Rahul

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