commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [all] Proposal: Jakarta Language Components
Date Sun, 05 Mar 2006 21:25:04 GMT
On 3/5/06, Martin Cooper <martinc@apache.org> wrote:
> On 3/5/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> >
> > Time to stop being negative, here is what I would like to happen next.
> >
> >
> > I hereby propose the creation of a new Jakarta entity named 'Jakarta
> > Language Components'.
> >
> > This will be formed from the following codebases:
> > [lang]
> > [io]
> > [collections] - expected to divide
> > [primitives]
> > [codec]
> > [id] - on exit from sandbox
> > [convert] - if ever developed
> >
> > I currently believe these are related, but out of scope:
> > [beanutils] - logging is an issue
> > [pool] - is pooling more J2EE than J2SE
> > [oro]/[regexp] - specialised knowledge
> > [math] - specialised, has dependencies
> >
> > Jakarta Language Components will:
> > - develop multiple independent components
> > - each component will have no dependencies
> > - each component will have no configuration
> > - each component provides an extension to the J2SE
> > - code judged by would it be out of place in the J2SE
> > - a component typically has a broad API (many callable methods)
> > - each method typically does relatively little processing
> > - have mailing lists (user/dev/commit)
> > - not have a sandbox
> > - use jakarta-general (or jakarta-dev?) for cross group issues
> >
> >
> > 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.
>
>
> +1. Despite my general reluctance to break up the Commons community, I like
> this. It creates a clearly focussed other-Commons that should leave both
> communities healthy - and probably leave the current Commons more manageable
> in the process.

-1.

I've no problem with grouping those components together, or the name
of the grouping. It makes a lot of sense and fits nicely with HTTP
Components and Web Components. Course the other one becomes
BiggerCommonsComponents or Misc Components or something. Also, Jakarta
File Components will want to have IO in along with FileUpload, VFS,
Compress.

My reason for being against the idea is that it's a continuation of
Jakarta as a set of communities without much overlap.

I'm +1 to the idea of splitting Commons up into groupings - provided
we don't break up the community.

Hen

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


Mime
View raw message