Re: Representing project inactivity on the site
Henri Yandell wrote: * ECS, ORO, Regexp to be moved to a label of Inactive. Think of Regexp as of low maintenance project. There are several issues reported against it, and some of those can be (relatively) easy fixed and new release can be pushed out. It would be disappointing if such labeling makes it harder to maintain project or forces users to look elsewhere. 'Mature' seems to better reflect current state of the project. Vadim - 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. snip/ THREAD-OT 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: quote - a component typically has a broad API (many callable methods) - each method typically does relatively little processing /quote 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-devm=114158923925088w=2 [2] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=108601577728628w=2 (see bottom half) [3] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=108612848615661w=2 [4] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=112621821630874w=2 (see bottom half) /THREAD-OT 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? snap/ 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: svn commit: r383773 - /jakarta/site/xdocs/site/whoweare.xml
On 3/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sandymac Date: Mon Mar 6 20:30:58 2006 New Revision: 383773 URL: http://svn.apache.org/viewcvs?rev=383773view=rev Log: Added myself, Sandy McArthur, to whoweare.xml Modified: jakarta/site/xdocs/site/whoweare.xml snip/ Hi Sandy, Welcome to Jakarta ;-) This won't actually do anything to the site unless you: a) build the site (I think you'll need JDK1.5 to avoid copious whitespace/attribute rearrangement diffs) b) svn ci the matching whoweare.html in docs/ c) svn up /www/jakarta.apache.org/ -Rahul Modified: jakarta/site/xdocs/site/whoweare.xml URL: http://svn.apache.org/viewcvs/jakarta/site/xdocs/site/whoweare.xml?rev=383773r1=383772r2=383773view=diff == --- jakarta/site/xdocs/site/whoweare.xml (original) +++ jakarta/site/xdocs/site/whoweare.xml Mon Mar 6 20:30:58 2006 @@ -848,6 +848,13 @@ POI and Xindice. The problem is that he's too picky to be satisfied :-) /p p +bSandy McArthur/b (sandymac at apache.org) +br/ +a href=http://Sandy.McArthur.org/;Sandy/a works at the +a href=http://www.ufl.edu;University of Florida/a as a programmer. +He is a commiter for Commons focusing on the Pool project. +/p +p bDan Milstein/b (danmil at shore.net) br/ Dan works as an independent consultant in the Boston area. This is his - 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. snip / 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: svn commit: r383773 - /jakarta/site/xdocs/site/whoweare.xml
On 07/03/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sandymac Date: Mon Mar 6 20:30:58 2006 New Revision: 383773 URL: http://svn.apache.org/viewcvs?rev=383773view=rev Log: Added myself, Sandy McArthur, to whoweare.xml Modified: jakarta/site/xdocs/site/whoweare.xml snip/ Hi Sandy, Welcome to Jakarta ;-) This won't actually do anything to the site unless you: a) build the site (I think you'll need JDK1.5 to avoid copious whitespace/attribute rearrangement diffs) Hopefully not ... I'm fairly sure I fixed those. If not, let me know. But feel free to use 1.5 anyway ! S. - 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. snip / 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, 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?
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?
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. snip/ THREAD-OT 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. /THREAD-OT 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? snap/ 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 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: snip/ 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. snap/ 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-devm=114166343620440w=2 -Rahul 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 Tue, 7 Mar 2006, Rahul Akolkar wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 7 Mar 2006, Rahul Akolkar wrote: snip/ 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. snap/ 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-devm=114166343620440w=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?
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?
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?
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?
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: snip/ 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. snap/ 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-devm=114166343620440w=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?
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: snip/ 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. snap/ 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-devm=114166343620440w=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?
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: snip/ 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. snap/ 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-devm=114166343620440w=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]
[PROPOSAL] Jakarta Language Components
Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. 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 [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' 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 JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Hola, General +1 to everything Stephen proposes, -0 on the name as previously discussed in another thread. Jorg's Jakarta Rocks is a good proposal, other 1-word suggestions would be great. I'll throw in a couple of simple ones from the same root idea: Augmento (Spanish for enhancing...) or Miglio (Italian, short for miglioramento)... Yoav On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. 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 [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' 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 JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - 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: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. ... Jakarta Language Components will: - develop multiple independent components I will vote -1 based soley on item 1 of the list for the reasons I've already explained. I think that having ANOTHER jak-commons is a fundementally bad idea. If these are truly enahancements to JavaSE, they are one community, and share a mailinglist...then make them one distribution and version them together. - each component will have no dependencies - each component will have no configuration - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Andrew C. Oliver wrote: Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. ... Jakarta Language Components will: - develop multiple independent components I will vote -1 based soley on item 1 of the list for the reasons I've already explained. I think that having ANOTHER jak-commons is a fundementally bad idea. If these are truly enahancements to JavaSE, they are one community, and share a mailinglist...then make them one distribution and version them together. See the list for how many users complain already now about the *size* of some of those components. Obviously these are often people from the J2ME camp or people dealing with applets. OTOH if a look at my last bigger app and the proposed list, I find only two of the packages, that I did not use. The problem with providing a combined jar of all and separated ones are again the dependencies, that will be a real mess then. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Hello, other 1-word suggestions would be great. since they're language components, you can call them Syllables :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Roland Weber wrote: Hello, other 1-word suggestions would be great. since they're language components, you can call them Syllables :-) I understand the desire for 'fancy' names, but it misses the point unfortunately. This is merely a grouping a several *Jakarta* components. A fancy name should be thought of as implying TLP status. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: 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 [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' 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 JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Andrew C. Oliver wrote: I will vote -1 based soley on item 1 of the list for the reasons I've already explained. I think that having ANOTHER jak-commons is a fundementally bad idea. If these are truly enahancements to JavaSE, they are one community, and share a mailinglist...then make them one distribution and version them together. An interesting perspective. Firstly, this isn't another commons, but a breakout from the existing commons using the existing code in the existing packages. Secondly, jar hell is real and painful. We know that and strive for backwards compatibility. My hope is that this group will be able to create a single jar file in addition to the component jar files. Why? Because our users seem to want both. Thirdly, because it moves one step forward towards a world where Jakarta consists of lots of small components, each at the same level, grouped for communication, development and practicality. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On 3/7/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. ... Jakarta Language Components will: - develop multiple independent components I will vote -1 based soley on item 1 of the list for the reasons I've already explained. I think that having ANOTHER jak-commons is a fundementally bad idea. If these are truly enahancements to JavaSE, they are one community, and share a mailinglist...then make them one distribution and version them together. please correct me if i am off here, but my understanding is that this is not really ANOTHER commons. this is a proposal to pull out and group a subset of existing commons subprojects with the intent of simplifying and clarifying the current jumble that is commons. if anything, this looks to me like a step in the direction you are advocating. once like commons components are gathered together there may be potential to package them into one release. impeding it because it does not immediately go as far as you want it to seems picky. or do you really think these ought to be left alongside things like Jelly and ultimately packaged with them?? - each component will have no dependencies - each component will have no configuration - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -Andy - 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: [PROPOSAL] Jakarta Language Components
+1 The only negative is the dev@ as opposed to [EMAIL PROTECTED] Hen On Tue, 7 Mar 2006, Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. 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 [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' 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 JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - 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]
Other Jakarta Components
Thomas Dudziak wrote: Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition. My hope is that in a few months we will have a mentality of working on *Jakarta* components, not working on commons (or any other) components. To achieve this will require other groupings. Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and Velocity, may have real issues with this whole grouping philosophy. My answer is to *not* force communities that are truly content with the status quo to change. Each grouping will have: - a bland name (Jakarta Xxx Components) - an identity (how and why does the group exist) - sufficient size (to be active not inactive) - mailing lists (one ML for all Jakarta doesn't work) - SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED] What I will say is that its too early to worry about website issues. For now, all we need to know is that there will be a link somewhere to each component, and probably a single page describing each group. Pages such as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED] Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Thomas Dudziak wrote: Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition. My hope is that in a few months we will have a mentality of working on *Jakarta* components, not working on commons (or any other) components. To achieve this will require other groupings. Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and Velocity, may have real issues with this whole grouping philosophy. My answer is to *not* force communities that are truly content with the status quo to change. Each grouping will have: - a bland name (Jakarta Xxx Components) - an identity (how and why does the group exist) - sufficient size (to be active not inactive) - mailing lists (one ML for all Jakarta doesn't work) - SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED] What I will say is that its too early to worry about website issues. For now, all we need to know is that there will be a link somewhere to each component, and probably a single page describing each group. Pages such as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED] I understand this, but I wonder whether this move will have an immediate negative effect on the other Jakarta components in terms of developer attention both to the projects and to the users. As you say, probably not so much for the direct Jakarta sub-projects like Velocity, but for the other commons components. As a side note, perhaps this is an opportunity to evaluate if there are better homes for some of the components ? E.g. betwixt/digester/jxpath could benefit from going to XML commons, dbcp and dbutils from going to DB etc. ? cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Tue, 7 Mar 2006, Stephen Colebourne wrote: Thomas Dudziak wrote: Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition. My hope is that in a few months we will have a mentality of working on *Jakarta* components, not working on commons (or any other) components. To achieve this will require other groupings. Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and Velocity, may have real issues with this whole grouping philosophy. My answer is to *not* force communities that are truly content with the status quo to change. If the status quo is that they can be independent subprojects without having to pay attention to the rest - then I'm going to eventually be forcing it - if they want to be a TLP, they can be a TLP. The only alternative I see to that is that Jakarta as a whole declares that it wants to be an umbrella and we'll go to the board with that. How POI, Velocity and Turbine fit into things is definitely still up for grabs. Velocity and Turbine both contain components - making them groupings already - so it wouldn't be a huge change for them to treat those components as top-level Jakarta components within a particular grouping. ie: Fulcrum is a component in Jakarta within the Turbine grouping. Each grouping will have: - a bland name (Jakarta Xxx Components) +1. - an identity (how and why does the group exist) +1 - sufficient size (to be active not inactive) +0. Not too concerned about an inactive grouping - as long as we - mailing lists (one ML for all Jakarta doesn't work) +1 - SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED] Not sure what the differentiation between [EMAIL PROTECTED] and [EMAIL PROTECTED] would be. +1 to sharing common issues - an as you know I'd like to take that a bit further to issues that they have in common (ie both have svn reorg issues, even if different bits of svn). I'd like to add: * Groupings are NOT reflected in svn. jakarta/lang/trunk not jakarta/jlc/lang/trunk. What I will say is that its too early to worry about website issues. For now, all we need to know is that there will be a link somewhere to each component, and probably a single page describing each group. Pages such as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED] +1. I'd also like us to avoid the word charter when discussing the description for a grouping. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: As a side note, perhaps this is an opportunity to evaluate if there are better homes for some of the components ? E.g. betwixt/digester/jxpath could benefit from going to XML commons, dbcp and dbutils from going to DB etc. ? +1, except are we going to see community go with them? I don't think we should be dumping code over the wall so we don't have to worry about it any more. Of course this is not about throwing e.g. digester over to XML and forget about it. Rather, it would simply be its new home with its own mailing list(s). And all developers who are already working on it, would continue to do so in its new place. I mean, there is not much overlap between e.g. digester and lang as it is, except that there are people who do work on both (that's the whole point of this discussion, or not ?) But they could do the same in both places, with the benefit that some other developers from the new place might also be interested (e.g. dbutils would probably attract DB developers, e.g. me). And users would able to choose a more specialized mailing list with less noise. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Tue, 7 Mar 2006, Thomas Dudziak wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: As a side note, perhaps this is an opportunity to evaluate if there are better homes for some of the components ? E.g. betwixt/digester/jxpath could benefit from going to XML commons, dbcp and dbutils from going to DB etc. ? +1, except are we going to see community go with them? I don't think we should be dumping code over the wall so we don't have to worry about it any more. Of course this is not about throwing e.g. digester over to XML and forget about it. Rather, it would simply be its new home with its own mailing list(s). And all developers who are already working on it, would continue to do so in its new place. I mean, there is not much overlap between e.g. digester and lang as it is, except that there are people who do work on both (that's the whole point of this discussion, or not ?) But they could do the same in both places, with the benefit that some other developers from the new place might also be interested (e.g. dbutils would probably attract DB developers, e.g. me). And users would able to choose a more specialized mailing list with less noise. Yeah, sounds like it's worth sounding out XML about whether they'd be interested. DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO would fit nicely. And obviously the component developers should agree first whether they think this is a good idea. And if they are interested, I can ask the DB PMC if they agree, as well. However, I have no direct connections to XML PMC, and since I'm not an comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me (though I would if you want me to). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
From the Velocity perspective, this sounds a little like our subproject. We've discussed this and aren't ready to move to TLP status. (we're not a framework!). But there are a couple of different efforts under the Velocity umbrella, specifically Velocity Engine, Velocity Tools, DVSL. Maybe Anakia as well (though it's current distributed with the Velocity jar). If we flatten out Jakarta, I'd definitely like to see a Velocity group. Best, WILL On 3/7/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO would fit nicely. And obviously the component developers should agree first whether they think this is a good idea. And if they are interested, I can ask the DB PMC if they agree, as well. However, I have no direct connections to XML PMC, and since I'm not an comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me (though I would if you want me to). Tom - 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: snip/ 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-devm=114166343620440w=2 Yep, I agree with your email there. Sorry for snapping, snap/ 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: Other Jakarta Components
On Tue, 7 Mar 2006, Thomas Dudziak wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO would fit nicely. And obviously the component developers should agree first whether they think this is a good idea. And if they are interested, I can ask the DB PMC if they agree, as well. I don't think there is any active maintenance for DbUtils, and I suspect not for DBCP either. I've been meaning to do some work on DbUtils - but I have a long list of those. However, I have no direct connections to XML PMC, and since I'm not an comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me (though I would if you want me to). Go ahead and propose each one (db and xml) separately on commons-dev. See if anyone speaks up against it - I suspect you'll find that for betwixt/jxpath/dbutils/dbcp there won't be a huge amount of talk, though Struts uses digester (I think) and they might have an opinion (they're well represented on commons-dev). We're only going to end up with a Jakarta XML Components at this rate; which would suck. The DB ones would either be in a Jakarta SQL Components (suck) or a Jakarta Enterprise Components. The latter isn't so bad, but as Geronimo shows - there's a lot in J2EE and I suspect that grouping would balloon. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
Definitely in favour of turning things like Velocity, POI, Turbine into groupings if at all possible. Less likely with POI I suspect. I'd hope that this would mean: SVN Auth - everyone in Jakarta has write permissions SVN structure - jakarta/dvsl, jakarta/velocity/, jakarta/anakia (not sure how much tools differs from engine) Mailing lists - Encouraged to use general@ for the more administrative issues Website - Existence of a velocity grouping One option would be to discuss a Jakarta Scripting Components or something group, but that seems like it'd be going too far. Hen On Tue, 7 Mar 2006, Will Glass-Husain wrote: From the Velocity perspective, this sounds a little like our subproject. We've discussed this and aren't ready to move to TLP status. (we're not a framework!). But there are a couple of different efforts under the Velocity umbrella, specifically Velocity Engine, Velocity Tools, DVSL. Maybe Anakia as well (though it's current distributed with the Velocity jar). If we flatten out Jakarta, I'd definitely like to see a Velocity group. Best, WILL On 3/7/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO would fit nicely. And obviously the component developers should agree first whether they think this is a good idea. And if they are interested, I can ask the DB PMC if they agree, as well. However, I have no direct connections to XML PMC, and since I'm not an comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me (though I would if you want me to). Tom - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Definitely in favour of turning things like Velocity, POI, Turbine into groupings if at all possible. Less likely with POI I suspect. I'd hope that this would mean: SVN Auth - everyone in Jakarta has write permissions SVN structure - jakarta/dvsl, jakarta/velocity/, jakarta/anakia (not sure how much tools differs from engine) jakarta/tools is (and will always be) very different from engine. Mailing lists - Encouraged to use general@ for the more administrative issues Website - Existence of a velocity grouping One option would be to discuss a Jakarta Scripting Components or something group, but that seems like it'd be going too far. definitely too far. Velocity is about templates, not scripts. trust me, there is a difference. :) i'd be ok with a Jakarta Template Components group. Hen On Tue, 7 Mar 2006, Will Glass-Husain wrote: From the Velocity perspective, this sounds a little like our subproject. We've discussed this and aren't ready to move to TLP status. (we're not a framework!). But there are a couple of different efforts under the Velocity umbrella, specifically Velocity Engine, Velocity Tools, DVSL. Maybe Anakia as well (though it's current distributed with the Velocity jar). If we flatten out Jakarta, I'd definitely like to see a Velocity group. Best, WILL On 3/7/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would point back to Jakarta for a dependency on [pool], but that helps to foster intra-project involvement. Betwixt, Digester and JXPath strike me as a bit more to swallow and XML might not want to taking such bites. You want to go ahead and ask them? Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO would fit nicely. And obviously the component developers should agree first whether they think this is a good idea. And if they are interested, I can ask the DB PMC if they agree, as well. However, I have no direct connections to XML PMC, and since I'm not an comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me (though I would if you want me to). Tom - 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 - 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: Other Jakarta Components
On Tue, 7 Mar 2006, Stephen Colebourne wrote: Thomas Dudziak wrote: Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition. This one is a bit of a catch-22. I've definitely warmed to this point - we need to be encouraging people to start talking about groupings, not to try and partition Jakarta based on some architectual schematic. However - if felt of ourselves as a single community - there wouldn't be an imposition from suggesting what you wanted to do with the code that you, as a PMC member, are responsible for (ie all of Jakarta). As it is the suggestion that your opinion on Velocity counts for as much as Nathan's opinion on Velocity feels unhealthy. This is when consensus would have to come in. I could suggest Jakarta Scripting Components: Velocity [not dvsl or anakia] EL Jelly BSF but people are going to happily disagree and point out why I'm wrong. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: Roland Weber wrote: Hello, other 1-word suggestions would be great. since they're language components, you can call them Syllables :-) I understand the desire for 'fancy' names, but it misses the point unfortunately. This is merely a grouping a several *Jakarta* components. A fancy name should be thought of as implying TLP status. +1 for the idea and also for the bland name - one of the things that I personally like about the I guess soon-to-be-defunct (sob, groan, choke j-c charter. Thanks, Stephen for pushing this forward. On the mailing list issue, I assume you mean we would have a jlc-dev, and jlc-user as well as the Jakarta-dev that you mention. Also, while this is technically [OT] here and probably deserves its own thread on j-c-dev, I would like to see [id] adopted as part of the formation of jlc - i.e., let it graduate into the new entity. Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
Thomas Dudziak wrote: On 3/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Thomas Dudziak wrote: Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition. My hope is that in a few months we will have a mentality of working on *Jakarta* components, not working on commons (or any other) components. To achieve this will require other groupings. Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and Velocity, may have real issues with this whole grouping philosophy. My answer is to *not* force communities that are truly content with the status quo to change. Each grouping will have: - a bland name (Jakarta Xxx Components) - an identity (how and why does the group exist) - sufficient size (to be active not inactive) - mailing lists (one ML for all Jakarta doesn't work) - SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED] What I will say is that its too early to worry about website issues. For now, all we need to know is that there will be a link somewhere to each component, and probably a single page describing each group. Pages such as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED] I understand this, but I wonder whether this move will have an immediate negative effect on the other Jakarta components in terms of developer attention both to the projects and to the users. As you say, probably not so much for the direct Jakarta sub-projects like Velocity, but for the other commons components. This is a good question and the one that has always given me pause when thinking about breaking up j-c. My expectation, though, is that like me personally, many of the people that will be active in jlc will also remain active in other components. The benefit will be for new contributors or those who want to just focus on the jlc components. The does it make sense as an extension to JSE? scoping criteria is also a powerful means of focussing effort for this group. As a side note, perhaps this is an opportunity to evaluate if there are better homes for some of the components ? E.g. betwixt/digester/jxpath could benefit from going to XML commons, dbcp and dbutils from going to DB etc. ? Definitely, but I think it is best to first get jlc set up and then let these discussions happen independently. Changes should be driven by the people in the communities who want to make them. Phil cheers, Tom - 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: svn commit: r383773 - /jakarta/site/xdocs/site/whoweare.xml
On 3/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sandymac Date: Mon Mar 6 20:30:58 2006 New Revision: 383773 URL: http://svn.apache.org/viewcvs?rev=383773view=rev Log: Added myself, Sandy McArthur, to whoweare.xml Modified: jakarta/site/xdocs/site/whoweare.xml snip/ Hi Sandy, Welcome to Jakarta ;-) This won't actually do anything to the site unless you: a) build the site (I think you'll need JDK1.5 to avoid copious whitespace/attribute rearrangement diffs) b) svn ci the matching whoweare.html in docs/ c) svn up /www/jakarta.apache.org/ Done. thanks for the directions. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of FrontPage by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/FrontPage -- * [JakartaReport] * [JakartaIssues] * [LicenceIssues] - * [ApacheBranding] === Jakarta Infrastructure === @@ -52, +51 @@ * [AC2k5US] - ApacheCon 2005 San Diego * [ApacheAtJavaOne2005] - === Sub Project Management === + === Organizing Jakarta === + * [Reorganization2006] * [SubProjectProposals] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of FrontPage by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/FrontPage The comment on the change is: Lacked energy to do this page - gonna look at bugs instead :) -- === Organizing Jakarta === - * [Reorganization2006] * [SubProjectProposals] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
