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/05 21:07:21 UTC
[all] Proposal: Jakarta Language Components
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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Torsten Curdt <tc...@apache.org>.
>> What about tagging the components? :-P
>
> Gets a bit complicated to use tagging when mailing lists are involved.
> Development discussions have to happen in a single place.
Sorry, should probably have used ";-P" not just ":-P"
Was not meant serious - although it actually is an
interesting idea the more I think about it.
...but OT for this discussion.
cheers
--
Torsten
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/5/06, Dion Gillard <di...@gmail.com> wrote:
> On 3/6/06, Torsten Curdt <tc...@apache.org> wrote:
> >
> > > It's not "administatively forcing a separation", it's a natural
> > > consequence
> > > of a particular group of components growing up together and
> > > "graduating"
> > > with a common purpose. The HttpClient component grew into the
> > > Jakarta HTTP
> > > Components subproject, and the Jakarta Web Components subproject
> > > will likely
> > > absorb some Commons components as well. What makes it wrong, or even
> > > different, for a group of Java-language-focussed components to
> > > "graduate"
> > > into Jakarta Language Components? To me, it's simply a natural
> > > evolution of
> > > the community.
> >
> > ...on the other hand it might hard to decide whether some belongs to
> > that
> > grouping or not. The definition of "language focussed" is just too
> > blurry IMO.
>
>
>
> For example, does email fit into the language components?
csv? :) Which raises the question of what about the Sandbox.
> What about tagging the components? :-P
Gets a bit complicated to use tagging when mailing lists are involved.
Development discussions have to happen in a single place.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Dion Gillard <di...@gmail.com>.
On 3/6/06, Torsten Curdt <tc...@apache.org> wrote:
>
> > It's not "administatively forcing a separation", it's a natural
> > consequence
> > of a particular group of components growing up together and
> > "graduating"
> > with a common purpose. The HttpClient component grew into the
> > Jakarta HTTP
> > Components subproject, and the Jakarta Web Components subproject
> > will likely
> > absorb some Commons components as well. What makes it wrong, or even
> > different, for a group of Java-language-focussed components to
> > "graduate"
> > into Jakarta Language Components? To me, it's simply a natural
> > evolution of
> > the community.
>
> ...on the other hand it might hard to decide whether some belongs to
> that
> grouping or not. The definition of "language focussed" is just too
> blurry IMO.
For example, does email fit into the language components?
What about tagging the components? :-P
>
> cheers
> --
> Torsten
>
>
--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris
Re: [all] Proposal: Jakarta Language Components
Posted by Torsten Curdt <tc...@apache.org>.
> It's not "administatively forcing a separation", it's a natural
> consequence
> of a particular group of components growing up together and
> "graduating"
> with a common purpose. The HttpClient component grew into the
> Jakarta HTTP
> Components subproject, and the Jakarta Web Components subproject
> will likely
> absorb some Commons components as well. What makes it wrong, or even
> different, for a group of Java-language-focussed components to
> "graduate"
> into Jakarta Language Components? To me, it's simply a natural
> evolution of
> the community.
...on the other hand it might hard to decide whether some belongs to
that
grouping or not. The definition of "language focussed" is just too
blurry IMO.
What about tagging the components? :-P
cheers
--
Torsten
Re: [all] Proposal: Jakarta Language Components
Posted by Martin Cooper <ma...@apache.org>.
On 3/5/06, Sandy McArthur <sa...@gmail.com> wrote:
>
> On 3/5/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 3/5/06, Martin Cooper <ma...@apache.org> wrote:
> > > +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.
>
> -1
> I'm basically with Henri here. I am fine with Commons being like the
> high school lunch cafeteria that naturally subdivides itself into
> groups. Just like it doesn't matter that the jocks (almost) never
> mingle with the chess club, they are both able to use the same
> facilities without problems. There is no reason to administratively
> enforce a separation.
It's not "administatively forcing a separation", it's a natural consequence
of a particular group of components growing up together and "graduating"
with a common purpose. The HttpClient component grew into the Jakarta HTTP
Components subproject, and the Jakarta Web Components subproject will likely
absorb some Commons components as well. What makes it wrong, or even
different, for a group of Java-language-focussed components to "graduate"
into Jakarta Language Components? To me, it's simply a natural evolution of
the community.
--
Martin Cooper
> I'm +1 to the idea of splitting Commons up into groupings - provided
> > we don't break up the community.
>
> -0 to splitting into groupings, I'm fine with organizing the layout of
> websites into groups that just cosmetic categories but I'm not going
> to endorse anything that splits Commons developers.
>
> --
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Proposal: Jakarta Language Components
Posted by Sandy McArthur <sa...@gmail.com>.
On 3/5/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/5/06, Martin Cooper <ma...@apache.org> wrote:
> > +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.
-1
I'm basically with Henri here. I am fine with Commons being like the
high school lunch cafeteria that naturally subdivides itself into
groups. Just like it doesn't matter that the jocks (almost) never
mingle with the chess club, they are both able to use the same
facilities without problems. There is no reason to administratively
enforce a separation.
> I'm +1 to the idea of splitting Commons up into groupings - provided
> we don't break up the community.
-0 to splitting into groupings, I'm fine with organizing the layout of
websites into groups that just cosmetic categories but I'm not going
to endorse anything that splits Commons developers.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Martin Cooper <ma...@apache.org>.
On 3/5/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 3/5/06, Martin Cooper <ma...@apache.org> wrote:
> > On 3/5/06, Stephen Colebourne <sc...@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.
Jakarta *is* a set of communities, whether you like it or not. A community
is an organic entity that lives and breathes on its own. It is what it is;
you (meaning anyone, not just you, Hen) can't just decide that it should be
something different from what it has grown into organically, over a period
of several years. If a set of communities ends up folding into a single
community, that will happen naturally, not because someone decided that's
what it "should" be.
--
Martin Cooper
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
>
>
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/5/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Henri Yandell wrote:
> > -1.
> > My reason for being against the idea is that it's a continuation of
> > Jakarta as a set of communities without much overlap.
>
> This proposal, as most others do simply represents reality - that
> Jakarta does contain sub-communities. Maybe the Apache board has trouble
> with that, but in the end most of us don't.
The current design of the Apache foundation has trouble with it.
In terms of options - my current one is to campaign strongly for
Jakarta to do as much as possible to be a single community. If our
consensus is strongly that we want Jakarta to be nothing more than an
umbrella of communities, then I'll have to change tack and suggest
various ideas that will piss the foundation off :)
Namely - PPMCs, individual subproject chairs, subcharters - in effect
a copy of the Incubator and the ASF. The fact that Jakarta is nowadays
about small components would be my reasoning behind this - it can't be
a normal TLP and its subprojects very strongly do not want to be TLPs
of their own (in some cases they couldn't be, in others they don't
want to leave). The outcome would be either that we could go ahead
with an Incubator style structure, or that we'd have to terminate
Jakarta and subprojects would have a choice of TLP or die (that's the
only time I think the stick would be anywhere in all of this long term
planning).
The one thing I won't do is have the ASF having one definition of a
project, and Jakarta having another. I really, really hate it when
people look the other way and ignore that what they're saying doesn't
represent reality (they being the ASF in this case).
> I would suggest that the concern shouldn't be with the presence or
> number of sub-communities, but instead the aim should be to offer
> something positive at the Jakarta level that pulls everyone within
> together. The carrot works better than the stick in OSS.
I'm all ears if you have thoughts in that direction :)
> (Maybe Jakarta-level could have a single user ML for all Jakarta. Or
> even better focus on a Jakarta-wide forum system.)
The shared community needs to be at the oversight level; this just
causes pain for the users. I'd be +1 on a user list per component if
that's what was wanted or a single user list - it's not that important
to the community issue.
> > I'm +1 to the idea of splitting Commons up into groupings - provided
> > we don't break up the community.
>
> This doesn't read right. A community comes together around the ML. And
> thats a good thing, not a bad thing. This proposal tries to take one
> large extended family and break it into two smaller more manageable units.
>
> Perhaps you are thinking of a website only grouping? Well that adresses
> no real issues I can see. Its a shallow view on the problem. It leaves
> the underlying issues. One ML for all Jakarta won't work - its artificial.
>
> And how is Jakarta Http Components, or Jakarta Web Components OK, but
> not jakarta Language Components?
They're not. Change my -1 to a -0; JLC is as good a grouping as JHC
and JWC: but the grouping concept as you've described it is not enough
to make any of them successes.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> -1.
> My reason for being against the idea is that it's a continuation of
> Jakarta as a set of communities without much overlap.
This proposal, as most others do simply represents reality - that
Jakarta does contain sub-communities. Maybe the Apache board has trouble
with that, but in the end most of us don't.
(Note: it was correct to ensure the true TLPs went to TLP, but what is
left probably won't ever go TLP. And yet what is left is very definitely
multiple communities.)
I would suggest that the concern shouldn't be with the presence or
number of sub-communities, but instead the aim should be to offer
something positive at the Jakarta level that pulls everyone within
together. The carrot works better than the stick in OSS.
(Maybe Jakarta-level could have a single user ML for all Jakarta. Or
even better focus on a Jakarta-wide forum system.)
> I'm +1 to the idea of splitting Commons up into groupings - provided
> we don't break up the community.
This doesn't read right. A community comes together around the ML. And
thats a good thing, not a bad thing. This proposal tries to take one
large extended family and break it into two smaller more manageable units.
Perhaps you are thinking of a website only grouping? Well that adresses
no real issues I can see. Its a shallow view on the problem. It leaves
the underlying issues. One ML for all Jakarta won't work - its artificial.
And how is Jakarta Http Components, or Jakarta Web Components OK, but
not jakarta Language 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] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/5/06, Martin Cooper <ma...@apache.org> wrote:
> On 3/5/06, Stephen Colebourne <sc...@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
Re: [all] Proposal: Jakarta Language Components
Posted by Martin Cooper <ma...@apache.org>.
On 3/5/06, Stephen Colebourne <sc...@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.
--
Martin Cooper
Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Proposal: Jakarta Language Components
Posted by James Ring <sj...@jdns.org>.
Hi Stephen,
On Monday 06 March 2006 07:07, Stephen Colebourne 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
Does CLI fit into the picture? Or do you feel that there are issues with it
that would prevent it from becoming part of the proposed JLC?
> 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)
I think the project should continue to have just user and development mailing
lists, unless list traffic gets to such a point where people are complaining
of the volume.
If you take Linux, for example, it's a very large project with a very high
volume mailing list encompassing all disparate concerns in the Linux kernel.
Maybe the cost of splitting the community mailing lists into many small lists
is high, and the payoff isn't great?
> - not have a sandbox
> - use jakarta-general (or jakarta-dev?) for cross group issues
Would the JLC be distributed as one jar file? If so, could JLC components
depend on each other? What are your opinions on distribution issues like
that?
> Stephen
Thanks.
Regards,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [all] Proposal: Jakarta Language Components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Rearranging Jakarta into different islands than the islands of today
> doesn't convince me that the project will see any change in community
> overlap
As you may have noticed on general@incubator.apache.org, I've raised this
issue in terms of communities based upon codebase oversight and ontological
domain. We are structured for the former, but fertilization of ideas often
comes from the latter, and so I feel that we need to look at how to preserve
the former and foster the latter.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
> Henri Yandell wrote:
> > It all comes back to my main problem - there is no Jakarta community.
> > You're right about organic growth being the best way, let it happen.
> > JLC will head off and enjoy its health etc. For Jakarta as a whole
> > organic-growth of the subcommunities is not good.
>
> I'd actually like to suggest that having two or three viable and active
> communities within Jakarta which want to share stuff will help create
> the Jakarta-level community you so desire. Be patient, and don't force
> it :-)
Rearranging Jakarta into different islands than the islands of today
doesn't convince me that the project will see any change in community
overlap - in fact if it does create overlap, it'll be due to poor
decision making on our part at drawing up the components - or a need
for groupings to be more like taggings (though that'll be a pain in
the arse to deal with I think).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Phil Steitz wrote:
> I disagree there, and that is what actually led me to move to +1 for
> Stephen's proposal, when I have consistently argued against breaking
> j-c up in the past. I think it is reasonable to attack the "problem"
> (which, like some others I am not sure is as much a problem as some of
> us think) of lack of organization by letting self-organizing ideas
> like the one being discussed here move forward. In other words,
> instead of asking, "OK, so now how to we organize the rest of the
> stuff?" we instead focus on getting JLC going and then keep an open
> mind for the rest. Maybe the remaining commons components continue
> just fine for another several years. Maybe the struts components move
> over to struts and the JEE-ish things move into Geronimo or JWC really
> happens and they mostly move there. Maybe [math] finally gets a job
> and leaves home. And maybe none of this happens, or it happens slowly
> and independently. The key thing is to have it driven by people who
> want to make it happen.
+1. And thanks for typing what I was about to type.
Henri Yandell wrote:
> It all comes back to my main problem - there is no Jakarta community.
> You're right about organic growth being the best way, let it happen.
> JLC will head off and enjoy its health etc. For Jakarta as a whole
> organic-growth of the subcommunities is not good.
I'd actually like to suggest that having two or three viable and active
communities within Jakarta which want to share stuff will help create
the Jakarta-level community you so desire. Be patient, and don't force
it :-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/6/06, Phil Steitz <ph...@gmail.com> wrote:
<snip/>
> The key thing is to have it driven by people who
> want to make it happen.
>
> So who is going to make JWC happen :-)
>
<snap/>
Given that:
* I have the drive for working on the RDC taglib, and
* Taglibs committed itself to JWC last year
unless the second part changes, transitivity seems to suggest there is
atleast me. The rest of the JWC future shall be organic, we'll have an
open mind, and so on ...
(other details may come up on general@, please follow that thread if
you're interested)
-Rahul
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/6/06, Martin Cooper <ma...@apache.org> wrote:
> On 3/6/06, Phil Steitz <ph...@gmail.com> wrote:
> >
> > On 3/6/06, Henri Yandell <fl...@gmail.com> wrote:
> >
> > <snip/>
> >
> > > It might make things simpler to draw up an entire future re-org of
> > > Jakarta. See who gets dropped through the cracks and decide if we have
> > > to kill, accept or leave them to stand alone. There are some obvious
> > > ones for JWC, and some that just don't seem to fit and would have to
> > > stand alone.
> >
> > I disagree there, and that is what actually led me to move to +1 for
> > Stephen's proposal, when I have consistently argued against breaking
> > j-c up in the past. I think it is reasonable to attack the "problem"
> > (which, like some others I am not sure is as much a problem as some of
> > us think) of lack of organization by letting self-organizing ideas
> > like the one being discussed here move forward. In other words,
> > instead of asking, "OK, so now how to we organize the rest of the
> > stuff?" we instead focus on getting JLC going and then keep an open
> > mind for the rest. Maybe the remaining commons components continue
> > just fine for another several years. Maybe the struts components move
> > over to struts and the JEE-ish things move into Geronimo or JWC really
> > happens and they mostly move there. Maybe [math] finally gets a job
> > and leaves home. And maybe none of this happens, or it happens slowly
> > and independently. The key thing is to have it driven by people who
> > want to make it happen.
>
>
> Nicely said. Exactly. Organic growth.
It all comes back to my main problem - there is no Jakarta community.
You're right about organic growth being the best way, let it happen.
JLC will head off and enjoy its health etc. For Jakarta as a whole
organic-growth of the subcommunities is not good.
Maybe the answer is that we just accept Jakarta as a collection of
communities and find out what the ASF want to do about that.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Martin Cooper <ma...@apache.org>.
On 3/6/06, Phil Steitz <ph...@gmail.com> wrote:
>
> On 3/6/06, Henri Yandell <fl...@gmail.com> wrote:
>
> <snip/>
>
> > It might make things simpler to draw up an entire future re-org of
> > Jakarta. See who gets dropped through the cracks and decide if we have
> > to kill, accept or leave them to stand alone. There are some obvious
> > ones for JWC, and some that just don't seem to fit and would have to
> > stand alone.
>
> I disagree there, and that is what actually led me to move to +1 for
> Stephen's proposal, when I have consistently argued against breaking
> j-c up in the past. I think it is reasonable to attack the "problem"
> (which, like some others I am not sure is as much a problem as some of
> us think) of lack of organization by letting self-organizing ideas
> like the one being discussed here move forward. In other words,
> instead of asking, "OK, so now how to we organize the rest of the
> stuff?" we instead focus on getting JLC going and then keep an open
> mind for the rest. Maybe the remaining commons components continue
> just fine for another several years. Maybe the struts components move
> over to struts and the JEE-ish things move into Geronimo or JWC really
> happens and they mostly move there. Maybe [math] finally gets a job
> and leaves home. And maybe none of this happens, or it happens slowly
> and independently. The key thing is to have it driven by people who
> want to make it happen.
Nicely said. Exactly. Organic growth.
--
Martin Cooper
So who is going to make JWC happen :-)
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Proposal: Jakarta Language Components
Posted by Phil Steitz <ph...@gmail.com>.
On 3/6/06, Henri Yandell <fl...@gmail.com> wrote:
<snip/>
> It might make things simpler to draw up an entire future re-org of
> Jakarta. See who gets dropped through the cracks and decide if we have
> to kill, accept or leave them to stand alone. There are some obvious
> ones for JWC, and some that just don't seem to fit and would have to
> stand alone.
I disagree there, and that is what actually led me to move to +1 for
Stephen's proposal, when I have consistently argued against breaking
j-c up in the past. I think it is reasonable to attack the "problem"
(which, like some others I am not sure is as much a problem as some of
us think) of lack of organization by letting self-organizing ideas
like the one being discussed here move forward. In other words,
instead of asking, "OK, so now how to we organize the rest of the
stuff?" we instead focus on getting JLC going and then keep an open
mind for the rest. Maybe the remaining commons components continue
just fine for another several years. Maybe the struts components move
over to struts and the JEE-ish things move into Geronimo or JWC really
happens and they mostly move there. Maybe [math] finally gets a job
and leaves home. And maybe none of this happens, or it happens slowly
and independently. The key thing is to have it driven by people who
want to make it happen.
So who is going to make JWC happen :-)
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/5/06, Stephen Colebourne <sc...@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
If logging were removed?
> [pool] - is pooling more J2EE than J2SE
Not sure. Should we also consider a J-JEE-C? With this being J-JSE-C?
[pool], [dbcp] and [JCS] all seem related.
> [oro]/[regexp] - specialised knowledge
This is a hard one. Specialised yes, but definitely a JLC fit and
otherwise we'll just have a Jakarta Regexp Components group.
> [math] - specialised, has dependencies
It's not a fit anyway - [math] goes way, way beyond the JDK.
Others:
[bcel]? Again a specialized knowledge one.
[dbutils]? Do we consider jdbc to be JEE?
[email]? JEE?
It might make things simpler to draw up an entire future re-org of
Jakarta. See who gets dropped through the cracks and decide if we have
to kill, accept or leave them to stand alone. There are some obvious
ones for JWC, and some that just don't seem to fit and would have to
stand alone.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/5/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> [id] - on exit from sandbox
<snip>
> - not have a sandbox
To effect this, I think that the sandbox should be at the Jakarta
level and not at the Commons level. What do you think?
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 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
[all] Rest of commons
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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] Proposal: Jakarta Language Components
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/5/06, Stephen Colebourne <sc...@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
Re: [all] Proposal: Jakarta Language Components
Posted by Phil Steitz <ph...@gmail.com>.
On 3/5/06, Stephen Colebourne <sc...@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.
That was a good idea - the pause and reflect bit ;-)
I am +1, as long as we agree informally to keep the "overlap" stuff
mentioned here and elsewhere alive.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
Would it be possible for this proposal and modifications based on the
following 26 emails to be sent to general@jakarta for greater
discussion?
Hen
On 3/5/06, Stephen Colebourne <sc...@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.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Henri Yandell <fl...@gmail.com>.
On 3/6/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> --- James Ring wrote:
> > Does CLI fit into the picture? Or do you feel that
> > there are issues with it
> > that would prevent it from becoming part of the
> > proposed JLC?
> CLI has dependencies at present. A slimmed down CLIv2
> might be appropriate. Question is whether we believe
> this would be an appropriate J2SE enhancement.
Looks like 1 import dependency on Lang - and it's in the old CLI 1 API.
So definitely +1 for CLI in JLC with CLI1 removed or CLI2 removed and
the import gone.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/6/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
<snip/>
> --- Henri Yandell wrote:
> > To effect this, I think that the sandbox should be at
> > the Jakarta level and not at the Commons level.
>
> +1. But I think you may need a jakarta-dev list.
>
<snap/>
Yes, and this should also help in:
* Getting support from other Jakarta committers rather than expecting
them to be involved in Commons to contribute (and vote).
* Making it easier for narrow-deep API'ed components to be "accepted".
-Rahul
> Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Thomas Dudziak <to...@gmail.com>.
On 3/6/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> --- James Ring wrote:
> > Does CLI fit into the picture? Or do you feel that
> > there are issues with it
> > that would prevent it from becoming part of the
> > proposed JLC?
> CLI has dependencies at present. A slimmed down CLIv2
> might be appropriate. Question is whether we believe
> this would be an appropriate J2SE enhancement.
I probably don't know the history of this, but why would the presence
of dependencies on other JLC components make it unappropriate ?
Shouldn't this be a matter of what it does ?
> Thats why I attempted to describe it clearly.
>
> J2SE-based - so no email, xml, xpath, mbeans, daemon,
> db...
> Suitable for adding to the J2SE, so no validator,
> chain, ...
> Broad-shallow API - many small routines, not one task
> per component
Some of these possibly don't even belong to Jakarta (anymore), e.g.
xml/xpath/digester/betwixt could be handled in XML commons, dbutils in
DB etc.
cheers,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Proposal: Jakarta Language Components
Posted by Stephen Colebourne <sc...@btopenworld.com>.
--- James Ring wrote:
> Does CLI fit into the picture? Or do you feel that
> there are issues with it
> that would prevent it from becoming part of the
> proposed JLC?
CLI has dependencies at present. A slimmed down CLIv2
might be appropriate. Question is whether we believe
this would be an appropriate J2SE enhancement.
--- James Ring wrote:
> Would the JLC be distributed as one jar file? If so,
> could JLC components
> depend on each other? What are your opinions on
> distribution issues like that?
I would expect each component to have its own jar.
As with commons, there probably should be a
jlc-combo.jar too, but thats optional.
--- Torsten Curdt wrote:
> ...on the other hand it might hard to decide
> whether some belongs to that grouping or not.
> The definition of "language focussed" is just
> too blurry IMO.
--- Dion Gillard wrote:
> For example, does email fit into the language
components?
--- Henri Yandell wrote:
> csv?
Thats why I attempted to describe it clearly.
J2SE-based - so no email, xml, xpath, mbeans, daemon,
db...
Suitable for adding to the J2SE, so no validator,
chain, ...
Broad-shallow API - many small routines, not one task
per component
CSV is probably JLC.
--- Torsten Curdt wrote:
> What about tagging the components?
Tagging is just a website niceity. It doesn't solve
the size issue of commons. There are too many of us
here. Discussions get drowned out or missed.
--- Phil Steitz wrote:
> I am +1, as long as we agree informally to keep the
> "overlap" stuff mentioned here and elsewhere alive.
We have to. There needs to be a jakarta-wide (no
longer commons-wide) place to discuss shared issues,
and share knowledge.
--- Henri Yandell wrote:
> To effect this, I think that the sandbox should be
at
> the Jakarta level and not at the Commons level.
+1. But I think you may need a jakarta-dev list.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org