RE: Jakarta Sandbox (was [VOTE])
On Sun, 2006-04-09 at 19:19 -0400, Noel J. Bergman wrote: > Andrew C. Oliver wrote: > > Then there is no NEED for a sandbox. > > As you know, the sandbox predates the Incubator, and AIUI, the Sandbox > exists so as to allow experiments without polluting the respository in such > manner that would confuse the public and ourselves about what is real and > what is play. There may be other ways in to achieve that goal. Agreed. I think much of the Sandbox concept owes its existence to the limitations of CVS, and that with Subversion and the recent jakarta-wide commit access a lot of the need for a sandbox is gone. A project which has ties to an existing one (eg a refactoring of common code out of a project into a "common component") can be done in a sandbox subdir of that project (sibling to trunk/tags/branches). Discussion can be held on that project's lists. Oversight is provided by the committers on that related project. When it's ready to be promoted, a simple "svn mv" and the creation of a separate email list will do the job. For projects which are brand new but likely to become part of jakarta commons, the existing commons sandbox (using the existing commons-dev list) seems appropriate to me. Oversight is provided by the commons community. Of course if the project is a kind of "language extension" then it might want to hang out on the proposed commons-lang-components list instead of the original commons list. Projects that originate outside apache and are being brought in go through the incubator of course. Oversight is provided by those kind apache committers who subscribe to the incubator lists. The only problem I see is largish projects that are originated by existing Apache committers and have no close affiliation to existing projects. There aren't likely to be very many of these. I would suggest that if such a project can't find an existing project willing to effectively "sponsor" it by allowing their own list and subversion dir to be used to host the project for a while, then it belongs in incubation. The other issue to consider is where websites for sandbox-status projects can live. I think it would be nice to group these together, eg under jakarta.apache.org/sandbox. This provides a way for such projects to publish sites while making it clear to users that they aren't yet "approved". To summarise: I suggest setting up a parent website for jakarta-wide sandbox stuff, and dropping the existing sandbox docs that encourage non-commons projects to come and play in the commons sandbox. Otherwise things can be pretty much left as they are... Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 3/23/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Wed, 2006-03-22 at 15:51 -0300, Felipe Leme wrote: > > Hi Rahul (and others), > > > > First of all, sorry for the delay (but as they say here "Better later > > than never" :-) Thanks for the update. > > Still, I think it worths to create a separate sub-project for the Standard > > Taglibs - even if it's DOA on activity, it's still a different project > > (because of the TCK, history, importance of JSTL, etc...) > > we're trying to move away from sub-projects so possible a standards > grouping might make more sense. a home for EL as well ;) > If this ever comes about, and is expanded to be beyond JCP, such as W3C standards as well, then the third candidate is Commons (sandbox) SCXML [1],[2]. -Rahul [1] (spec) http://www.w3.org/TR/scxml/ [2] (impl) http://jakarta.apache.org/commons/sandbox/scxml/ > - robert > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Wed, 2006-03-22 at 15:51 -0300, Felipe Leme wrote: > Hi Rahul (and others), > > First of all, sorry for the delay (but as they say here "Better later > than never" :-) +1 > Still, I think it worths to create a separate sub-project for the Standard > Taglibs - even if it's DOA on activity, it's still a different project > (because of the TCK, history, importance of JSTL, etc...) we're trying to move away from sub-projects so possible a standards grouping might make more sense. a home for EL as well ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Hi Rahul (and others), First of all, sorry for the delay (but as they say here "Better later than never" :-) No, I haven't heard from Pierre and I guess he haven't heard from his managers (as normally he is quick on answer such issues). My feeling is that Sun will not put any efforts on Jakarta Taglibs, as they have an OSI-approved OSS project going on with Glassfish. Still, I think it worths to create a separate sub-project for the Standard Taglibs - even if it's DOA on activity, it's still a different project (because of the TCK, history, importance of JSTL, etc...) -- Felipe Rahul Akolkar wrote: From the initial email in this thread: On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: Additionally we have Jakarta Web Components, which will take on various bits - including Jakarta Taglibs (can't recall if the Standard Taglib would go in there or not). No, AFAICT. Did you / Felipe hear back from Pierre? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 3/8/06, Yoav Shapira <[EMAIL PROTECTED]> wrote: > Good points... I guess we can wait with the fancy names until these > Jakarta X Component groupings become their own TLPs... Remember the > Rocks ;) > J*C then, going once, going twice ... (its been a long wait, for JWC atleast, I suspect once we're beyond the names, things may move faster?) -Rahul > Y > > On 3/8/06, sebb <[EMAIL PROTECTED]> wrote: > > On 08/03/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > > > "Jakarta Rocks Betwixt" (ignoring that the ones for JLC have boring names) > > > > > > Do we really need 3 catchy terms? > > > > > > From my point of view, the part that fancy names misses is that these are > > > not subprojects, they are just component groupings to make email and the > > > website easier to grasp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
>From the initial email in this thread: On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > Additionally we have Jakarta Web Components, which will take on various > bits - including Jakarta Taglibs (can't recall if the Standard Taglib > would go in there or not). No, AFAICT. Did you / Felipe hear back from Pierre? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Wed, 2006-03-08 at 16:54 +, sebb wrote: > I'd much prefer something like > > Jakarta Lang[uage] Components > Jakarta Web Components > etc > > I then have some idea what each contains, with having to remember that > Bogart means Language, and Bacall means Web etc. > > Otherwise, we might as well call them > > Jakarta Group A > Jakarta Group B > Jakarta Group C +1 Simple project or group names seem best to me. For us developers who are working with jakarta stuff daily clever names are not a nuisance because we soon memorise what they are associated with. However I think they just make it harder for others to find projects they are interested in. These clever names can also be hard on non-native english speakers. For them, the name can be a completely meaningless phrase. Silk? Syllable? And of course there's the earlier point that what's currently under discussion is *not* a project or a TLP; it's just a grouping of jakarta stuff to reduce mail-list and website overload. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Good points... I guess we can wait with the fancy names until these Jakarta X Component groupings become their own TLPs... Remember the Rocks ;) Y On 3/8/06, sebb <[EMAIL PROTECTED]> wrote: > On 08/03/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > "Jakarta Rocks Betwixt" (ignoring that the ones for JLC have boring names) > > > > Do we really need 3 catchy terms? > > > > From my point of view, the part that fancy names misses is that these are > > not subprojects, they are just component groupings to make email and the > > website easier to grasp. > > +1 > > > This does put an onus on the website to make it easy to find the component > > you used to know was in Commons, ie) a simple component index etc. > > +1 > > I'd much prefer something like > > Jakarta Lang[uage] Components > Jakarta Web Components > etc > > I then have some idea what each contains, with having to remember that > Bogart means Language, and Bacall means Web etc. > > Otherwise, we might as well call them > > Jakarta Group A > Jakarta Group B > Jakarta Group C > > S. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 08/03/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > "Jakarta Rocks Betwixt" (ignoring that the ones for JLC have boring names) > > Do we really need 3 catchy terms? > > From my point of view, the part that fancy names misses is that these are > not subprojects, they are just component groupings to make email and the > website easier to grasp. +1 > This does put an onus on the website to make it easy to find the component > you used to know was in Commons, ie) a simple component index etc. +1 I'd much prefer something like Jakarta Lang[uage] Components Jakarta Web Components etc I then have some idea what each contains, with having to remember that Bogart means Language, and Bacall means Web etc. Otherwise, we might as well call them Jakarta Group A Jakarta Group B Jakarta Group C S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
"Jakarta Rocks Betwixt" (ignoring that the ones for JLC have boring names) Do we really need 3 catchy terms? From my point of view, the part that fancy names misses is that these are not subprojects, they are just component groupings to make email and the website easier to grasp. This does put an onus on the website to make it easy to find the component you used to know was in Commons, ie) a simple component index etc. Hen On Wed, 8 Mar 2006, Yoav Shapira wrote: Hola, Both Rocks and Syllables are a great suggestion ;) I disagee that a 1-word name implies TLP: just look at our current projects for many counter-examples. Most things under WS are 1-word where the TLP itself is two words, and WS is not a unique TLP in that respect. The inverse is also true, where we have numerous "technical" or "non-marketing-oriented" TLP names, like HTTP Server, DB, Directory, Logging, Web Services... There's a decent body of scholarly work that shows users (customers) identify more with 1-word "catchy" product (project) names. I think now's a decent chance to pick names like these, becuase it will increase the likelihood of new users and developers joining the community, maybe even reviving some of the dead-er projects. Moreover, as we've seen already, it's hard to make precise definitions of what's a "web" components versus just an "http" component, what's a "lang" component, etc, so the meaning of Jakarta Web Components is not crystal clear anyways. And if it's not clear to us discussing it here, you can be sure it's not clear to users who are not as savvy or familiar with the components. I guess the real background to this is that I'm hoping we're not just shuffling for the sake of shuffling. I'm trying to create some more incentives, however small (after all, the world runs on micromotives, according to some: http://www.cscs.umich.edu/abc/abc_ken/sld018.htm), for both existing and new people to involve themselves in these projects... All that said, I'm not -1 on a techie term like Jakarta Web Components -- if a lot of people want it, so be it. I'm a clear -0, very different from -1 ;) Yoav On 3/8/06, C. Grobmeier <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since those Java Language Components have some kind of Core nature, I think of something solid ... what about Jakarta Rocks 8-) This is great! - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDqhikv8rKBUE/T4RAjNiAJ9mIcD3AHQBQhIaetCDUTZxMlk9iwCdE2mH q6fhHvS1gXZWSXnAjDSaXLU= =bFY6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
How about Jakarta Pebbles? After a while we can start a project called bambam .. then wilma, then freddie .. wow imagine the possibilities with Bedrock! Yabba dabba doo! Sanjiva. On Wed, 2006-03-08 at 07:35 -0500, Yoav Shapira wrote: > Hola, > Both Rocks and Syllables are a great suggestion ;) > > I disagee that a 1-word name implies TLP: just look at our current > projects for many counter-examples. Most things under WS are 1-word > where the TLP itself is two words, and WS is not a unique TLP in that > respect. The inverse is also true, where we have numerous "technical" > or "non-marketing-oriented" TLP names, like HTTP Server, DB, > Directory, Logging, Web Services... > > There's a decent body of scholarly work that shows users (customers) > identify more with 1-word "catchy" product (project) names. I think > now's a decent chance to pick names like these, becuase it will > increase the likelihood of new users and developers joining the > community, maybe even reviving some of the dead-er projects. > > Moreover, as we've seen already, it's hard to make precise definitions > of what's a "web" components versus just an "http" component, what's a > "lang" component, etc, so the meaning of Jakarta Web Components is not > crystal clear anyways. And if it's not clear to us discussing it > here, you can be sure it's not clear to users who are not as savvy or > familiar with the components. > > I guess the real background to this is that I'm hoping we're not just > shuffling for the sake of shuffling. I'm trying to create some more > incentives, however small (after all, the world runs on micromotives, > according to some: http://www.cscs.umich.edu/abc/abc_ken/sld018.htm), > for both existing and new people to involve themselves in these > projects... > > All that said, I'm not -1 on a techie term like Jakarta Web Components > -- if a lot of people want it, so be it. I'm a clear -0, very > different from -1 ;) > > Yoav > > On 3/8/06, C. Grobmeier <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > > Since those Java Language Components have some kind of Core nature, I > > > think > > > of something solid ... what about > > > > > > Jakarta Rocks > > > > 8-) This is great! > > - - Chris > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.2.1 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFEDqhikv8rKBUE/T4RAjNiAJ9mIcD3AHQBQhIaetCDUTZxMlk9iwCdE2mH > > q6fhHvS1gXZWSXnAjDSaXLU= > > =bFY6 > > -END PGP SIGNATURE- > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Yoav Shapira > Senior Architect > Nimalex LLC > 1 Mifflin Place, Suite 310 > Cambridge, MA, USA > [EMAIL PROTECTED] / www.yoavshapira.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Hola, Both Rocks and Syllables are a great suggestion ;) I disagee that a 1-word name implies TLP: just look at our current projects for many counter-examples. Most things under WS are 1-word where the TLP itself is two words, and WS is not a unique TLP in that respect. The inverse is also true, where we have numerous "technical" or "non-marketing-oriented" TLP names, like HTTP Server, DB, Directory, Logging, Web Services... There's a decent body of scholarly work that shows users (customers) identify more with 1-word "catchy" product (project) names. I think now's a decent chance to pick names like these, becuase it will increase the likelihood of new users and developers joining the community, maybe even reviving some of the dead-er projects. Moreover, as we've seen already, it's hard to make precise definitions of what's a "web" components versus just an "http" component, what's a "lang" component, etc, so the meaning of Jakarta Web Components is not crystal clear anyways. And if it's not clear to us discussing it here, you can be sure it's not clear to users who are not as savvy or familiar with the components. I guess the real background to this is that I'm hoping we're not just shuffling for the sake of shuffling. I'm trying to create some more incentives, however small (after all, the world runs on micromotives, according to some: http://www.cscs.umich.edu/abc/abc_ken/sld018.htm), for both existing and new people to involve themselves in these projects... All that said, I'm not -1 on a techie term like Jakarta Web Components -- if a lot of people want it, so be it. I'm a clear -0, very different from -1 ;) Yoav On 3/8/06, C. Grobmeier <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Since those Java Language Components have some kind of Core nature, I think > > of something solid ... what about > > > > Jakarta Rocks > > 8-) This is great! > - - Chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.1 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEDqhikv8rKBUE/T4RAjNiAJ9mIcD3AHQBQhIaetCDUTZxMlk9iwCdE2mH > q6fhHvS1gXZWSXnAjDSaXLU= > =bFY6 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Since those Java Language Components have some kind of Core nature, I think > of something solid ... what about > > Jakarta Rocks 8-) This is great! - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDqhikv8rKBUE/T4RAjNiAJ9mIcD3AHQBQhIaetCDUTZxMlk9iwCdE2mH q6fhHvS1gXZWSXnAjDSaXLU= =bFY6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On Tue, 7 Mar 2006, Rahul Akolkar wrote: > > > > > I expressed a similar opinion in response to the JLC proposal on > > commons-dev. Given that we're in this mess with intermingling threads > > on commons-dev@ and general@, forgive me for cross-posting that as a > > hyperlink: > > > > http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166343620440&w=2 > > Yep, I agree with your email there. > > Sorry for snapping, > Bah, no sorries needed. I must say, to your credit, you recovered very quickly ;-P -Rahul > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Henri Yandell wrote: I think there's pretty much wide-spread agreement to the pain of that issue, in and out of Commons. Stephen's suggestion for the JLC ones are that they would not have any dependencies (currently they don't). The 'deep end' stuff tends to depend on these, ie) there will be far more roC->JLC dependencies than internal roC dependencies. Also the Commons components (JLC especially) maintain backwards compat within minor versions (as we all do) so the only times you should be having this pain is when Apache Foo depends on vers 1.0 and Apache Bar depends on vers 2.0. Lang (1.x, 2.x) and Collections (1.x, 2.x, 3.x) are the only ones that spring to mind that have more than one major version release. So I'm not sure the issue is as painful as your memory paints it. Now when the container depends on commons, that seems to cause more pain (cf commons-logging complaints). No the commons issue is pretty painful in large environments and with "the wild" of live support. Yes Tomcat's dependence on commons-logging is a pain. I'd feel more comfortable with a single versioned release rather than a bunch more pieces that have to be put together. Let them live together and die together. -Andy Hen On Tue, 7 Mar 2006, Andrew C. Oliver wrote: Personally I think that commons is a bit TOO open. I'm not sure the Java world can suffer another project designed to throw us into circular dependency hell. These little mini-component projects that all depend on each other combined with the inherent crappiness of Java classloading (.NET does this better) are just misery to those of us who have to work with them and support real people using them. I don't think it is "deep end" "shallow end" -- it is that these are all interdependent and versioned seperately and then end up with different parts of apache requiring vers 1 and others requiring 1.1 and 1 having a horrible bug in it. -andy Henri Yandell wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: I hope to help in "dealing with" roC. Yep, that's my chief point on the thirty four pieces, not two pieces - the roC still needs solutions. Yet more where we should be thinking about our project (Jakarta) and not just making one step (JLC) and being happy with it. I expressed a similar opinion in response to the JLC proposal on commons-dev. Given that we're in this mess with intermingling threads on commons-dev@ and general@, forgive me for cross-posting that as a hyperlink: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166343620440&w=2 Yep, I agree with your email there. Sorry for snapping, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
I think there's pretty much wide-spread agreement to the pain of that issue, in and out of Commons. Stephen's suggestion for the JLC ones are that they would not have any dependencies (currently they don't). The 'deep end' stuff tends to depend on these, ie) there will be far more roC->JLC dependencies than internal roC dependencies. Also the Commons components (JLC especially) maintain backwards compat within minor versions (as we all do) so the only times you should be having this pain is when Apache Foo depends on vers 1.0 and Apache Bar depends on vers 2.0. Lang (1.x, 2.x) and Collections (1.x, 2.x, 3.x) are the only ones that spring to mind that have more than one major version release. So I'm not sure the issue is as painful as your memory paints it. Now when the container depends on commons, that seems to cause more pain (cf commons-logging complaints). Hen On Tue, 7 Mar 2006, Andrew C. Oliver wrote: Personally I think that commons is a bit TOO open. I'm not sure the Java world can suffer another project designed to throw us into circular dependency hell. These little mini-component projects that all depend on each other combined with the inherent crappiness of Java classloading (.NET does this better) are just misery to those of us who have to work with them and support real people using them. I don't think it is "deep end" "shallow end" -- it is that these are all interdependent and versioned seperately and then end up with different parts of apache requiring vers 1 and others requiring 1.1 and 1 having a horrible bug in it. -andy Henri Yandell wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: I hope to help in "dealing with" roC. Yep, that's my chief point on the thirty four pieces, not two pieces - the roC still needs solutions. Yet more where we should be thinking about our project (Jakarta) and not just making one step (JLC) and being happy with it. I expressed a similar opinion in response to the JLC proposal on commons-dev. Given that we're in this mess with intermingling threads on commons-dev@ and general@, forgive me for cross-posting that as a hyperlink: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166343620440&w=2 Yep, I agree with your email there. Sorry for snapping, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Personally I think that commons is a bit TOO open. I'm not sure the Java world can suffer another project designed to throw us into circular dependency hell. These little mini-component projects that all depend on each other combined with the inherent crappiness of Java classloading (.NET does this better) are just misery to those of us who have to work with them and support real people using them. I don't think it is "deep end" "shallow end" -- it is that these are all interdependent and versioned seperately and then end up with different parts of apache requiring vers 1 and others requiring 1.1 and 1 having a horrible bug in it. -andy Henri Yandell wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: I hope to help in "dealing with" roC. Yep, that's my chief point on the thirty four pieces, not two pieces - the roC still needs solutions. Yet more where we should be thinking about our project (Jakarta) and not just making one step (JLC) and being happy with it. I expressed a similar opinion in response to the JLC proposal on commons-dev. Given that we're in this mess with intermingling threads on commons-dev@ and general@, forgive me for cross-posting that as a hyperlink: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166343620440&w=2 Yep, I agree with your email there. Sorry for snapping, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Tue, 7 Mar 2006, Will Glass-Husain wrote: I'm a few hours beind in this thread but... I like the idea of a Jakarta sandbox. Maybe we could put a page on the Jakarta web site with a few paragraphs explaining purpose and criteria. My impression is that this is an informal way to start exploring a new project or codebase - is that right? (and I'm assuming with looser standards regarding release and version numbering). It makes sense to make this Jakarta level - why force someone to be part of the commons community when doing this? Releases don't happen in the sandbox - it's very incubator like but less about bringing new code to Apache and more about creating new code at Apache. We definitely should have something on the website about it (probably lift whatever is on the Commons/Taglibs sites about them). I'm still 50/50 as to whether Commons CSV (which is currently a code donation) should have been a sandbox or incubator item. There's nothing like a committer sitting down and coding something from scratch in front of people to initiate involvement (imo anyway). This could be a good first step in equalizing Jakarta and commons. Yep. Or in my new mindset - of creating Jakarta community. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Hi, > Since those Java Language Components have some kind of Core nature, I think > of something solid ... what about Cool! Yoav -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Yoav Shapira wrote: > Hola, > >> > Yoav (who still bristles at the name Jakarta X Components -- we need >> > to get creative!) >> >> Jakarta Core Components/Pills/Marbles/Gems/Diamonds >> Jakarta Web Components/Pills/Marbles/Gems/Diamonds > > Gems would be a particularly interesting choice in light of the Ruby > use of the term ;) > > I'm hoping for more of a one-word catchy name, like we had for Apache > Silk. Actually, like Jakarta itself, or Tomcat, or Xerces, or Struts. > These one-word names catch on and suggest an identity that is far > more sticky than a technical 3-word term like "Jakarta Web > Components." Those types of names become another drop in the TLA > (three letter acronym) soup very quickly... Since those Java Language Components have some kind of Core nature, I think of something solid ... what about Jakarta Rocks ... and we have additional a nice word-play :D - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Tue, 7 Mar 2006, Rahul Akolkar wrote: On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: I hope to help in "dealing with" roC. Yep, that's my chief point on the thirty four pieces, not two pieces - the roC still needs solutions. Yet more where we should be thinking about our project (Jakarta) and not just making one step (JLC) and being happy with it. I expressed a similar opinion in response to the JLC proposal on commons-dev. Given that we're in this mess with intermingling threads on commons-dev@ and general@, forgive me for cross-posting that as a hyperlink: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166343620440&w=2 Yep, I agree with your email there. Sorry for snapping, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
I'm a few hours beind in this thread but... I like the idea of a Jakarta sandbox. Maybe we could put a page on the Jakarta web site with a few paragraphs explaining purpose and criteria. My impression is that this is an informal way to start exploring a new project or codebase - is that right? (and I'm assuming with looser standards regarding release and version numbering). It makes sense to make this Jakarta level - why force someone to be part of the commons community when doing this? This could be a good first step in equalizing Jakarta and commons. WILL On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > Over on Commons-Dev, Stephen has suggested that we split some of the > components out to form a Jakarta Language Components group. Consensus > is in favour of the idea, so I'm sure we'll see a vote on that and some > movement soon. > > Commons ID (and Commons CSV perhaps) are two elements in the Commons > Sandbox which would potentially go to JLC, but there are (wisely) no plans > for a separare JLC Sandbox. > > Additionally we have Jakarta Web Components, which will take on various > bits - including Jakarta Taglibs (can't recall if the Standard Taglib > would go in there or not). That has a Sandbox as well. > > Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - > which technically lost access to its sandbox - though I suspect it's been > a long time since it used it. > > To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox > merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine > it would mostly be the component groupings. > > Thoughts? > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ___ Forio Business Simulations Will Glass-Husain phone (415) 440-7500 x89 mobile (415) 235-4293 [EMAIL PROTECTED] www.forio.com
Re: Jakarta Sandbox?
On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On Tue, 7 Mar 2006, Rahul Akolkar wrote: > > > > > I hope to help in "dealing with" roC. > > Yep, that's my chief point on the thirty four pieces, not two pieces - the > roC still needs solutions. Yet more where we should be thinking about our > project (Jakarta) and not just making one step (JLC) and being happy with > it. > I expressed a similar opinion in response to the JLC proposal on commons-dev. Given that we're in this mess with intermingling threads on commons-dev@ and general@, forgive me for cross-posting that as a hyperlink: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166343620440&w=2 -Rahul > > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Tue, 7 Mar 2006, Rahul Akolkar wrote: On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Mon, 6 Mar 2006, Rahul Akolkar wrote: +1 -- its time to establish that there are two equally useful pieces here, with differing API styles, differing thresholds for involvement and therefore, potentially attracting differing audiences (at the user and developer level). The more shared developers we can retain the better, ofcourse its understood that individual interests will trump utopian views in this regard. I think this goes a bit too far. There aren't two pieces, there are thirty four. Stephen's proposal pulls a quarter of those out into a somewhat cohesive bundle based on the J2SE and a tendency to have XxxUtils classes. I'll henceforth keep that view to myself to minimize the noise, but it Please don't. It's a better one than mine. "broad shallow" is a better meme for the grouping than J2SE/XxxUtils. We (the Jakarta community - ie: this list), presuming we decide to go with the JLC proposal, still have to deal with the rest of Commons, and how the rest of Jakarta fits into this. ORO/Regexp/BCEL seem like possibles for JLC, ECS for JWC, Jelly+BSF+EL for some other place? I hope to help in "dealing with" roC. Yep, that's my chief point on the thirty four pieces, not two pieces - the roC still needs solutions. Yet more where we should be thinking about our project (Jakarta) and not just making one step (JLC) and being happy with it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Tue, 7 Mar 2006, Yoav Shapira wrote: Hola, Yoav (who still bristles at the name Jakarta X Components -- we need to get creative!) Jakarta Core Components/Pills/Marbles/Gems/Diamonds Jakarta Web Components/Pills/Marbles/Gems/Diamonds Gems would be a particularly interesting choice in light of the Ruby use of the term ;) I'm hoping for more of a one-word catchy name, like we had for Apache Silk. Actually, like Jakarta itself, or Tomcat, or Xerces, or Struts. These one-word names catch on and suggest an identity that is far more sticky than a technical 3-word term like "Jakarta Web Components." Those types of names become another drop in the TLA (three letter acronym) soup very quickly... We have a one-word catchy name - Jakarta :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Hola, > > Yoav (who still bristles at the name Jakarta X Components -- we need > > to get creative!) > > Jakarta Core Components/Pills/Marbles/Gems/Diamonds > Jakarta Web Components/Pills/Marbles/Gems/Diamonds Gems would be a particularly interesting choice in light of the Ruby use of the term ;) I'm hoping for more of a one-word catchy name, like we had for Apache Silk. Actually, like Jakarta itself, or Tomcat, or Xerces, or Struts. These one-word names catch on and suggest an identity that is far more sticky than a technical 3-word term like "Jakarta Web Components." Those types of names become another drop in the TLA (three letter acronym) soup very quickly... -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Sandbox?
Yoav Shapira wrote on Tuesday, March 07, 2006 2:47 PM: > Hola, > > > On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: >> >> Over on Commons-Dev, Stephen has suggested that we split some of the >> components out to form a Jakarta Language Components group. Consensus >> is in favour of the idea, so I'm sure we'll see a vote on that and >> some movement soon. >> >> Commons ID (and Commons CSV perhaps) are two elements in the Commons >> Sandbox which would potentially go to JLC, but there are (wisely) no >> plans for a separare JLC Sandbox. > >> Thoughts? > > Stating the obvious here -- commons-lang would also go into this new > Jakarta Language Components, right? > > Yoav (who still bristles at the name Jakarta X Components -- we need > to get creative!) Jakarta Core Components/Pills/Marbles/Gems/Diamonds Jakarta Web Components/Pills/Marbles/Gems/Diamonds Take your choice ... :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Hola, On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Over on Commons-Dev, Stephen has suggested that we split some of the > components out to form a Jakarta Language Components group. Consensus > is in favour of the idea, so I'm sure we'll see a vote on that and some > movement soon. > > Commons ID (and Commons CSV perhaps) are two elements in the Commons > Sandbox which would potentially go to JLC, but there are (wisely) no plans > for a separare JLC Sandbox. > Thoughts? Stating the obvious here -- commons-lang would also go into this new Jakarta Language Components, right? Yoav (who still bristles at the name Jakarta X Components -- we need to get creative!) -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On Mon, 6 Mar 2006, Rahul Akolkar wrote: > > > +1 -- its time to establish that there are two equally useful pieces > > here, with differing API styles, differing thresholds for involvement > > and therefore, potentially attracting differing audiences (at the user > > and developer level). The more shared developers we can retain the > > better, ofcourse its understood that individual interests will trump > > utopian views in this regard. > > I think this goes a bit too far. There aren't two pieces, there are thirty > four. Stephen's proposal pulls a quarter of those out into a somewhat > cohesive bundle based on the J2SE and a tendency to have XxxUtils classes. > I'll henceforth keep that view to myself to minimize the noise, but it may just be that we latched on to different bits of the proposal. From the original JLC proposal on commons-dev [1], related criteria are: - a component typically has a broad API (many callable methods) - each method typically does relatively little processing I see those specific criteria as a distillation of the discussions we've had numerous times on commons-dev. For instance, [2],[3] and [4] were trivial to find with the search string "broad shallow". (URLs below may get fragmented) [1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114158923925088&w=2 [2] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=108601577728628&w=2 (see bottom half) [3] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=108612848615661&w=2 [4] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=112621821630874&w=2 (see bottom half) > We (the Jakarta community - ie: this list), presuming we decide to go with > the JLC proposal, still have to deal with the rest of Commons, and how the > rest of Jakarta fits into this. ORO/Regexp/BCEL seem like possibles for > JLC, ECS for JWC, Jelly+BSF+EL for some other place? > I hope to help in "dealing with" roC. -Rahul > Will ask Stephen to repost the proposal here. > > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Mon, 6 Mar 2006, Rahul Akolkar wrote: +1 -- its time to establish that there are two equally useful pieces here, with differing API styles, differing thresholds for involvement and therefore, potentially attracting differing audiences (at the user and developer level). The more shared developers we can retain the better, ofcourse its understood that individual interests will trump utopian views in this regard. I think this goes a bit too far. There aren't two pieces, there are thirty four. Stephen's proposal pulls a quarter of those out into a somewhat cohesive bundle based on the J2SE and a tendency to have XxxUtils classes. We (the Jakarta community - ie: this list), presuming we decide to go with the JLC proposal, still have to deal with the rest of Commons, and how the rest of Jakarta fits into this. ORO/Regexp/BCEL seem like possibles for JLC, ECS for JWC, Jelly+BSF+EL for some other place? Will ask Stephen to repost the proposal here. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On 3/6/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > > Regarding sandboxes, the issue is really where the commit mails will go. > An experimental project that hopes to be promoted to community X really > should have its commit messages go to the mailing list for that > community. Other than that, what *is* a "sandbox" exactly? > IMO, this is a good point. Its like going to grad school, if you expect to graduate, at some point you must declare a major (sorry about the analogy, I'm aware they rarely work ;-). So unclear how this will play out in a Jakarta sandbox. Concretely speaking, if we mix the Commons and Taglibs sandboxes today, and assume that the groupings mentioned in this thread already exist -- some commits need to go the JWC, some to JLC and some to "Commons - JLC" (whatever that is). > In general, though, the split-off of Jakarta Language Components seems > wise. Commons email traffic is a pretty hefty burden, so halving it for > people only interested in one of the two new commons pieces is good. I > believe there are enough people interested in each community to allow > the separate pieces to thrive. Of course people should be encouraged to > subscribe to both where possible - and general always! > +1 -- its time to establish that there are two equally useful pieces here, with differing API styles, differing thresholds for involvement and therefore, potentially attracting differing audiences (at the user and developer level). The more shared developers we can retain the better, ofcourse its understood that individual interests will trump utopian views in this regard. -Rahul > Cheers, > > Simon > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Tue, 7 Mar 2006, Simon Kitching wrote: On Mon, 2006-03-06 at 22:42 -0500, Henri Yandell wrote: To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? I presume that a "commons committer" would have commit access to both old commons and Language Components? Having a separate commit list would set the barrier to high for movement between the groups. Actually, the proposed "jakarta-wide" commit access would be even better. I'm assuming the latter, yeah. I'm presuming we need to have a vote on the SVN one soon, there's not really been a lot discussion-wise there other than +1 and -1s. We're seen as a bit vote-happy - if there's consensus on something just do it, don't worry about the vote; but I don't think well get unaminous consensus on any of these issues. Regarding sandboxes, the issue is really where the commit mails will go. An experimental project that hopes to be promoted to community X really should have its commit messages go to the mailing list for that community. Other than that, what *is* a "sandbox" exactly? The sandbox is somewhere where existing Jakarta committers can start up new components - and any ASF committer can then join in. How it would work depends on which direction we go. I'd like to see us consider Jakarta a large bag of components with groupings to ease communication - but not form a subhierarchy. Components would either be in one grouping only, or many groupings - depending on whether we wanted to try the more interesting yet trickier latter option. In that case, the sandbox is quite simple - the same thing it is for Commons. Once something leaves the sandbox its groupings and communication lines would be determined. Commit emails would goto the [EMAIL PROTECTED] list. Another option is to use groupings as the new subprojects. In that case the sandbox becomes a bit more of an incubator, maybe with commit emails going back to the subprojects - or we lessen it so that the new subproject groupings can start things up internally and they would come to the sandbox when they wanted to engender cross-Jakarta activity, with commit emails going to [EMAIL PROTECTED] probably. I'm obviously not much of a salesman for the latter. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Mon, 2006-03-06 at 22:42 -0500, Henri Yandell wrote: > Over on Commons-Dev, Stephen has suggested that we split some of the > components out to form a Jakarta Language Components group. Consensus > is in favour of the idea, so I'm sure we'll see a vote on that and some > movement soon. > > Commons ID (and Commons CSV perhaps) are two elements in the Commons > Sandbox which would potentially go to JLC, but there are (wisely) no plans > for a separare JLC Sandbox. > > Additionally we have Jakarta Web Components, which will take on various > bits - including Jakarta Taglibs (can't recall if the Standard Taglib > would go in there or not). That has a Sandbox as well. > > Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - > which technically lost access to its sandbox - though I suspect it's been > a long time since it used it. > > To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox > merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine > it would mostly be the component groupings. > > Thoughts? I presume that a "commons committer" would have commit access to both old commons and Language Components? Having a separate commit list would set the barrier to high for movement between the groups. Actually, the proposed "jakarta-wide" commit access would be even better. Regarding sandboxes, the issue is really where the commit mails will go. An experimental project that hopes to be promoted to community X really should have its commit messages go to the mailing list for that community. Other than that, what *is* a "sandbox" exactly? In general, though, the split-off of Jakarta Language Components seems wise. Commons email traffic is a pretty hefty burden, so halving it for people only interested in one of the two new commons pieces is good. I believe there are enough people interested in each community to allow the separate pieces to thrive. Of course people should be encouraged to subscribe to both where possible - and general always! Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Forgot something. Stephen pointed out on Commons that this may mean a need for a [EMAIL PROTECTED] mailing list. We could try to use general@, but dev@ probably makes more sense. So +1 to that. Hen On Mon, 6 Mar 2006, Henri Yandell wrote: Over on Commons-Dev, Stephen has suggested that we split some of the components out to form a Jakarta Language Components group. Consensus is in favour of the idea, so I'm sure we'll see a vote on that and some movement soon. Commons ID (and Commons CSV perhaps) are two elements in the Commons Sandbox which would potentially go to JLC, but there are (wisely) no plans for a separare JLC Sandbox. Additionally we have Jakarta Web Components, which will take on various bits - including Jakarta Taglibs (can't recall if the Standard Taglib would go in there or not). That has a Sandbox as well. Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - which technically lost access to its sandbox - though I suspect it's been a long time since it used it. To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
