Re: Jakarta: too many similar projects?
I realize this isn't perfect. In some cases, it's not even good, the servlet EG sound like it belongs in the 'not good' category. I think we'd all like to see things changed so that there's a more open process for spec development, and there is a lot of interest on the JCP Exec Committee surrounding this issue. BTW, I *think* that you should be able to discuss the issues with any ASF member, if you are representing the ASF on the EG, not just other EG members. We all are bound by the agreements made by the ASF. For the record. I do not care to have ANY NDA-bound issues with those bound by NDAs. For work where I do not recieve financial compensation, I prefer to work in the open in a community/meritocratic/consensus basis rather than your non-community/non-meritocratic basis such as I feel strongly is the case with the JCP or any work which is bound by NDAs. I will regard any communication sent to me as non-confidential unless it is clearly stated in the subject line to be otherwise and will feel free to disclose it. NEVER send NDA material to me without my prior consent. If at some point I have to choose between Apache Membership and OpenSource. I will choose the latter. thanks, Andy geir Pier - 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: too many similar projects?
On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote: On 17/3/03 1:24 Hans Bergsten [EMAIL PROTECTED] wrote: I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. This is why I feel that my work as the official representative to that EG has been a failure :-( _MY_ failure... Well - it's always easy to look back and see what you could have done differently. Is it too late? geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 18/3/03 11:33 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote: On 17/3/03 1:24 Hans Bergsten [EMAIL PROTECTED] wrote: I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. This is why I feel that my work as the official representative to that EG has been a failure :-( _MY_ failure... Well - it's always easy to look back and see what you could have done differently. Is it too late? Yes... Certain new features are in... Not much we can do now... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Pier Fumagalli wrote: On 18/3/03 11:33 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote: On 17/3/03 1:24 Hans Bergsten [EMAIL PROTECTED] wrote: I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. This is why I feel that my work as the official representative to that EG has been a failure :-( _MY_ failure... Well - it's always easy to look back and see what you could have done differently. Is it too late? Yes... Certain new features are in... Not much we can do now... This is a long term run. And *you* should know that a Release always has some bugs left. ;-) Something we can learn for next time? Pier -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 18, 2003, at 03:08 PM, Pier Fumagalli wrote: On 18/3/03 11:33 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote: On 17/3/03 1:24 Hans Bergsten [EMAIL PROTECTED] wrote: I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. This is why I feel that my work as the official representative to that EG has been a failure :-( _MY_ failure... Well - it's always easy to look back and see what you could have done differently. Is it too late? Yes... Certain new features are in... Not much we can do now... Except vote against it, if that's what the ASF decides to do geir Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Mon, 17 Mar 2003 07:20, Hans Bergsten wrote: The NDA in the JCP agreement only applies to confidential information. After a public draft has been published, the info it contains is no longer confidential. Not necessarily. There are plenty of information that may not make it into the public draft but may still be relevent. In particular implications of certain design decisions. Even when a draft becomes public you may be restricted from discussing points and implications of decisions. -- Cheers, Peter Donald *-* * Faced with the choice between changing one's mind, * * and proving that there is no need to do so - almost * * everyone gets busy on the proof. * * - John Kenneth Galbraith * *-* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 12/3/03 6:53 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Tuesday, March 11, 2003, at 10:58 PM, Craig R. McClanahan wrote: As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. Take it a step further - how many internationally recognized standards processes will allow a single individual to propose, develop and deliver a standard? The JCP will... Yes, but why can I share with my friends concerns on the new W3C specifications and confront them in public, while I cannot do that with the JCP specifications??? Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise issues on the tomcat-dev mailing lists, all I can do is discuss them with Jon and Jason, as they both are on the spec... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Pier Fumagalli wrote: On 12/3/03 6:53 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Tuesday, March 11, 2003, at 10:58 PM, Craig R. McClanahan wrote: As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. Take it a step further - how many internationally recognized standards processes will allow a single individual to propose, develop and deliver a standard? The JCP will... Yes, but why can I share with my friends concerns on the new W3C specifications and confront them in public, while I cannot do that with the JCP specifications??? Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise issues on the tomcat-dev mailing lists, all I can do is discuss them with Jon and Jason, as they both are on the spec... You can raise and discuss your concerns in public as soon as a public draft of the spec is available, and there are at least two public drafts before the spec is finalized; plenty of time to make sure the larger community is aware of, and agrees with, what's being suggested. The NDA in the JCP agreement only applies to confidential information. After a public draft has been published, the info it contains is no longer confidential. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 16/3/03 20:20 Hans Bergsten [EMAIL PROTECTED] wrote: Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise issues on the tomcat-dev mailing lists, all I can do is discuss them with Jon and Jason, as they both are on the spec... You can raise and discuss your concerns in public as soon as a public draft of the spec is available, and there are at least two public drafts before the spec is finalized; plenty of time to make sure the larger community is aware of, and agrees with, what's being suggested. The NDA in the JCP agreement only applies to confidential information. After a public draft has been published, the info it contains is no longer confidential. As you are on the EG yourself, you know how hard it is to have one word removed from the next revision of the spec once it gets in :-) Just thinking out loud... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Sunday, March 16, 2003, at 02:53 PM, Pier Fumagalli wrote: On 12/3/03 6:53 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Tuesday, March 11, 2003, at 10:58 PM, Craig R. McClanahan wrote: As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. Take it a step further - how many internationally recognized standards processes will allow a single individual to propose, develop and deliver a standard? The JCP will... Yes, but why can I share with my friends concerns on the new W3C specifications and confront them in public, while I cannot do that with the JCP specifications??? You can do that after they are public specs, right? You can do the same with complete JCP-produced specs. Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise issues on the tomcat-dev mailing lists, all I can do is discuss them with Jon and Jason, as they both are on the spec... I realize this isn't perfect. In some cases, it's not even good, the servlet EG sound like it belongs in the 'not good' category. I think we'd all like to see things changed so that there's a more open process for spec development, and there is a lot of interest on the JCP Exec Committee surrounding this issue. BTW, I *think* that you should be able to discuss the issues with any ASF member, if you are representing the ASF on the EG, not just other EG members. We all are bound by the agreements made by the ASF. geir Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 16/3/03 23:32 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: BTW, I *think* that you should be able to discuss the issues with any ASF member, if you are representing the ASF on the EG, not just other EG members. We all are bound by the agreements made by the ASF. In fact I post my concerns to [EMAIL PROTECTED] and from time to time to [EMAIL PROTECTED] as well... But I can't to tomcat-dev (I know only two developers involved with the RI which are members: Remy and Craig, and the latter is on that list in virtue of his employment with Sun - looking at me Jon and Jason making fool of ourselves, of course) Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: Jakarta: too many similar projects?
| As you are on the EG yourself, you know how hard it is to have one word | removed from the next revision of the spec once it gets in :-) | | Just thinking out loud... | | Pier When a culture of discussion comes into conflict with a culture of bureaucracy, debate is not an optimal change instrument. Discussion cultures have evolution as their goal, while bureaucratic cultures have risk reduction and cost distribution as their goals. Bureaucracies can be changed by: 1. localized force (negotiation: private risk private cost distribution) 2. distributed feedback (metrics: public risk public cost distribution) 3. obsolescence (competition: public risk discontinuous costs) Apache is capable of exercising any or all of these, independent of circumstantial parties or objectives. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Pier Fumagalli wrote: On 16/3/03 20:20 Hans Bergsten [EMAIL PROTECTED] wrote: Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise issues on the tomcat-dev mailing lists, all I can do is discuss them with Jon and Jason, as they both are on the spec... You can raise and discuss your concerns in public as soon as a public draft of the spec is available, and there are at least two public drafts before the spec is finalized; plenty of time to make sure the larger community is aware of, and agrees with, what's being suggested. The NDA in the JCP agreement only applies to confidential information. After a public draft has been published, the info it contains is no longer confidential. As you are on the EG yourself, you know how hard it is to have one word removed from the next revision of the spec once it gets in :-) Just thinking out loud... I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. The JCP does not demand a closed room discussion all the way through; there's plenty of opportunity to raise concerns and put external pressure on the spec lead organization before the spec is final. Also, don't judge JCP based on a single EG. I'm in four EGs, and while there's been problems now and then in some of them, on the whole they work pretty good. I would be happier if the whole discussion leading up to a spec was more open (and the JCP allows for it), but even the way it's typically done, it's not all that bad. And compared to other spec organizations (W3C, ECMA, IETF, etc.), it has a pretty good track record on average for getting out specs with industry support in a reasonable time. There are exceptions, of course, but I'm sure that's true for all similar efforts. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 17/3/03 1:24 Hans Bergsten [EMAIL PROTECTED] wrote: I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. This is why I feel that my work as the official representative to that EG has been a failure :-( _MY_ failure... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
And I don't have the privilege of speaking with Sun's lawyers? Just don't return their calls. And when I'm fined and held for contempt of court will you be there with me? -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Thursday, March 13, 2003, at 08:52 AM, Andrew C. Oliver wrote: And I don't have the privilege of speaking with Sun's lawyers? Just don't return their calls. And when I'm fined and held for contempt of court will you be there with me? I had to go back and look at what I had responded to. Here's what I found : - Paulo Silveira wrote: What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? Call it portal.net and change the method names to begin with a capital letter. done. And I don't have the privilege of speaking with Sun's lawyers? Just don't return their calls. I was being flip, I guess. I want to make something clear - I don't advocate violating anyone's copyright or intellectual property claims, nor do I think you do. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Previously: Andrew C. Oliver wrote: Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Geir Magnusson Jr. wrote: Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) 1 out of 200 is misleading. I think you mean that Andrew had just 1 example out of 200 JSR. A more adequate comparison would be the other way round: . How many Apache projects are turned into JSR from the outside, not by the developers? I mean from people *not* in the team. (jserv/tomcat, the logging stuff, jetspeed) I bet that's it, please correct me. From the previous Pier email, it looks that we are close to 1.5 out of 3 than to 1 out of 200 (Just twisting as I see fit, following the previous example ;-) BTW, it looks like an excelent metrics for innovation in Open Source that the industry wants to standardize on OS projects. And later Geir Magnusson Jr. wrote: (...) One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. It depends on your semantics for recently. A historical account: People from IBM Germany approached the team (Raphael Luta, myself) in autumn 2000 (In the ApacheCON Europe) with a proposal. They were working in what became Websphere Portal Server and it looks like they would base it (partially, I'm sure) on the Jetspeed work. Kevin Burton, the original leader, misteriously disappeared from the project by then. This is how I became the speaker in this ApacheCON. A proposal was sent by the team to the list, and got heavily discussed (IRC, mail list, CVS repository). This (http://www.mail-archive.com/[EMAIL PROTECTED]/msg05121.html) excellent summary by Raphael Luta, who took most of the formalization effort gives an idea of the situation by Feb 2001. This (http://www.mail-archive.com/[EMAIL PROTECTED]/msg05089.html) post by Ingo Schuster (IBM voice in the list) gives idea to the level of discussion. After this, two things happened: * For the developers the priority was to stabilize the code base and have a release, *before* jumping to a heavy refactoring. * The IBM team (Ingo was the most visible part) disappeared completely from the public list. I have not been able to find anything in Google from those times, it seems they don't index mbox.gz archives (Please, Ovidiu, make them do it), so historicians will have to resort to http://jakarta.apache.org/mail/jetspeed-dev/ the .gz monthly archives :-) Everybody having more than enough work to do, and nobody really pushing the proposal (DOocrazy) it languished. In Dec 2001, a proposal was presented JSR 162 (Portlet API, Stefan Hepper, IBM http://www.jcp.org/en/jsr/detail?id=162). 6 days later JSR 167 (Java(TM) Portlet Specification, Alejandro Abdelnur, Sun Microsystems s/162/167/ in URL above) was presented. 20 Jan 2002 both were withdrawn, and 168 (with both leads s/167/168/ if you folloed the previous regexp). So, the industry jumped in. From then on, only David, Alejandro, Stefan, people in BEA, HP, etc. can tell what is going on. The proposal is not even in the Community Review stage one year later, as far as http://www.jcp.org/en/jsr/detail?id=168 says. In fact, it does not appear in the List JCP by stage page, which means it is still in fuzzyland. My recent community weather reports (http://blogs.cocoondev.org/stevenn/archives/000760.html) suggest that it is about to go into Community Review, or at least that there is movement inside. I could ellaborate on my prognosis techniques on demand. [EMAIL PROTECTED] busts of traffic seem good for predicting political stress. :-) No conclusions expected, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Wednesday, March 12, 2003, at 03:05 AM, Santiago Gala wrote: Previously: Andrew C. Oliver wrote: Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Geir Magnusson Jr. wrote: Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) 1 out of 200 is misleading. I think you mean that Andrew had just 1 example out of 200 JSR. Yes - IOW, there are lots of JSR, and even if Andy has legitimate complaints about how the Jetspeed JSR is happening, I can't see how it thus applies to the whole thing. A more adequate comparison would be the other way round: . How many Apache projects are turned into JSR from the outside, not by the developers? I mean from people *not* in the team. (jserv/tomcat, the logging stuff, jetspeed) I bet that's it, please correct me. From the previous Pier email, it looks that we are close to 1.5 out of 3 than to 1 out of 200 (Just twisting as I see fit, following the previous example ;-) The logging stuff was a real problem, and there is a *great* example of what still needs to change in the JCP. I detest the idea of logging in the standard JDK, and even worse, that it's not log4j. BTW, it looks like an excelent metrics for innovation in Open Source that the industry wants to standardize on OS projects. Definitely. And later Geir Magnusson Jr. wrote: (...) One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. It depends on your semantics for recently. A historical account: People from IBM Germany approached the team (Raphael Luta, myself) in autumn 2000 (In the ApacheCON Europe) with a proposal. They were working in what became Websphere Portal Server and it looks like they would base it (partially, I'm sure) on the Jetspeed work. Kevin Burton, the original leader, misteriously disappeared from the project by then. This is how I became the speaker in this ApacheCON. A proposal was sent by the team to the list, and got heavily discussed (IRC, mail list, CVS repository). This (http://www.mail-archive.com/[EMAIL PROTECTED]/ msg05121.html) excellent summary by Raphael Luta, who took most of the formalization effort gives an idea of the situation by Feb 2001. This (http://www.mail-archive.com/[EMAIL PROTECTED]/ msg05089.html) post by Ingo Schuster (IBM voice in the list) gives idea to the level of discussion. After this, two things happened: * For the developers the priority was to stabilize the code base and have a release, *before* jumping to a heavy refactoring. * The IBM team (Ingo was the most visible part) disappeared completely from the public list. I have not been able to find anything in Google from those times, it seems they don't index mbox.gz archives (Please, Ovidiu, make them do it), so historicians will have to resort to http://jakarta.apache.org/mail/jetspeed-dev/ the .gz monthly archives :-) Everybody having more than enough work to do, and nobody really pushing the proposal (DOocrazy) it languished. In Dec 2001, a proposal was presented JSR 162 (Portlet API, Stefan Hepper, IBM http://www.jcp.org/en/jsr/detail?id=162). 6 days later JSR 167 (Java(TM) Portlet Specification, Alejandro Abdelnur, Sun Microsystems s/162/167/ in URL above) was presented. 20 Jan 2002 both were withdrawn, and 168 (with both leads s/167/168/ if you folloed the previous regexp). Crystal clear :) So, the industry jumped in. From then on, only David, Alejandro, Stefan, people in BEA, HP, etc. can tell what is going on. The proposal is not even in the Community Review stage one year later, as far as http://www.jcp.org/en/jsr/detail?id=168 says. In fact, it does not appear in the List JCP by stage page, which means it is still in fuzzyland. Right. So what can you do? I'm assuming that the JetSpeed community didn't stop what they were doing, and second, IIRC, no one from the ASF stepped up to be spec lead. IOW, if we give a hoot about these JSRs, which we should, why don't *we* do it? Either a community a) doesn't want to, in which case it doesn't matter how the Evil Tyrannical Sun That Controls All behaves or b) it does, but only as a participant on the EG (from which info can be shared, I suppose - certainly something that can be negotiated with the leads on the JSR), or c) it does the JSR itself. I can't think of any other options. Thanks for the informative history, BTW. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m)
Re: Jakarta: too many similar projects?
Any set of interactions among people with common interests (incl. NDAs) creates a community. Those within may debate values or objectives, but a community only becomes real via the experiences of *external* people, That would be awesome. A community of people who are bound by NDAs and can't talk to each other! HA! Great. -Andy This is why Pringles should start a WiFi antenna company. Rich - 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: too many similar projects?
One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? Well - that's one way to describe it. The other way is that the JCP is how innovations are brought to the platform - the innovation was done before you tried to make a JSR. For example, Jason Hunter is running a JSR for JDOM. JDOM was done, and the benefits of the software clear, before he proposed the JSR So why does he need a JSR? -Andy geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta: too many similar projects?
Well - that's one way to describe it. The other way is that the JCP is how innovations are brought to the platform - the innovation was done before you tried to make a JSR. For example, Jason Hunter is running a JSR for JDOM. JDOM was done, and the benefits of the software clear, before he proposed the JSR JDom is an odd choice to support your side of the argument. JDom going the JSR route has killed forward progress on it for at nearly a year. It could have been a year of furious effort on their parts during which great advances were made, or they could have simply s/org.jdom/javax.xml.jdom/g and wasted the rest in burachracy ... I would guess they are NDA'd too much to say. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Either a community a) doesn't want to, in which case it doesn't matter how the Evil Tyrannical Sun That Controls All behaves or b) it does, but only as a participant on the EG (from which info can be shared, I suppose - certainly something that can be negotiated with the leads on the JSR), or c) it does the JSR itself. I can't think of any other options. d) Convince everyone that they don't need the silly JCP or JSRs and just set the standards and be real damn clear that we mean to set the de-facto standard while laughing at Ra. OpenSource is the standard. -Andy Thanks for the informative history, BTW. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Andrew C. Oliver wrote: What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? I think Sun's NDA is not that bad (but I don't want to re-read it to check). Once the JSR gets public, there is no provision against free use of what they call Residual knowledge polluting your brain. I can't remember what happens if you depart in the middle of the process. Or about extra time (6 months? 1 year? I really don't remember). You just grant a non-exclusive, transferrable license, to your knowledge, and you agree ND in aspects related to the JSR. For me, the crucial issue WRT the JCP process is enforcing release early, release often at regular steps, with all the caveats that might apply. Also, having a intermediate figure of free experts, which could answer in public questions, clarify or ask the community about controversial issues, without NDA. People in Apache would excel in this hub role. I think this is in the best interest of Apache, Sun, and possibly other participants in the community process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta: too many similar projects?
What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? Call it portal.net and change the method names to begin with a capital letter. done. -- Paulo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Wednesday, March 12, 2003, at 08:42 AM, Andrew C. Oliver wrote: One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? Then do a .NET portlet. Have a great time Well - that's one way to describe it. The other way is that the JCP is how innovations are brought to the platform - the innovation was done before you tried to make a JSR. For example, Jason Hunter is running a JSR for JDOM. JDOM was done, and the benefits of the software clear, before he proposed the JSR So why does he need a JSR? I dunno - can't speak for Jason. I suspect it was because he felt his model was a good one to standardize around. But you have to ask him... geir -Andy geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Wednesday, March 12, 2003, at 09:02 AM, Andrew C. Oliver wrote: Either a community a) doesn't want to, in which case it doesn't matter how the Evil Tyrannical Sun That Controls All behaves or b) it does, but only as a participant on the EG (from which info can be shared, I suppose - certainly something that can be negotiated with the leads on the JSR), or c) it does the JSR itself. I can't think of any other options. d) Convince everyone that they don't need the silly JCP or JSRs and just set the standards and be real damn clear that we mean to set the de-facto standard while laughing at Ra. OpenSource is the standard. Go for it. -Andy Thanks for the informative history, BTW. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Paulo Silveira wrote: What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? Call it portal.net and change the method names to begin with a capital letter. done. And I don't have the privilege of speaking with Sun's lawyers? -- Paulo - 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: too many similar projects?
d) Convince everyone that they don't need the silly JCP or JSRs and just set the standards and be real damn clear that we mean to set the de-facto standard while laughing at Ra. OpenSource is the standard. Go for it. I am... -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Wednesday, March 12, 2003, at 05:18 PM, Andrew C. Oliver wrote: Paulo Silveira wrote: What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? Call it portal.net and change the method names to begin with a capital letter. done. And I don't have the privilege of speaking with Sun's lawyers? Just don't return their calls. -- Paulo - 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] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
I would simply like to point out WHO is the specification lead of JSR-127 (see http://www.jcp.org/en/jsr/detail?id=127), and who was the initial author of Struts (see http://jakarta.apache.org/struts/volunteers.html)... Apache's concerns were Considering Sun's current position that JSRs may not be independently implemented under an open source license [...], and I'll let you make 1 + 1 here... Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug -- Yet each man kills the thing he loves, By each let this be heard, Some do it with a bitter look, Some with a flattering word. The coward does it with a kiss, The brave man with a sword! Oscar Wilde (1854-1900) British Author and Wit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Note that Sun's JCP NDA agreements burn the second and third completely. And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. So I'll say it more clearly JCP NDAs are anti-communalistic and twart innovation. Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. -Andy Geir Magnusson Jr. wrote: On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - 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: too many similar projects?
On Tuesday, March 11, 2003, at 06:40 PM, Andrew C. Oliver wrote: No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. Do you have any examples of this? You aren't confusing the material I submit to the ASF JCP group from the EC with whatever you are thinking about, are you? The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. What? How would that work, logically? I mean, if the committers on the JSR are bound by an NDA, and thus can't talk to the committers on a related Apache project, how can they communicate the 'major decisions' from this committee, and inflict them on the project? Some sort of 'double-secret' commit? Add code that no one can look at? There is no project here at the ASF that isn't open for public review. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. I'm starting to think this is a troll. Committers are promoted by their community. Sun has nothing to do with it. Further, most JSR's have nothing to do with Sun, except that Sun is financing the process management. The spec leads, in conjunction with the expert group, get copyright of the spec, dictate the license terms, etc, etc, etc. Sun has nothing to do with it, unless Sun is the spec lead. I'll be the first to say that the JCP is far from perfect, but what you are saying here doesn't make any sense. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. There is no reason why a JSR can't be totally open. It's up to the spec lead, as is the license. The innovation to the platform is brought by people like you and me that decide we have an API, technology, etc, that is appropriate for addition to the platform. The innovation happens before the JSR even starts. No one proposes a JSR to do something innovative that we haven't thought of yet. They do something innovative that they have done something with already. So I'll say it more clearly JCP NDAs are anti-communalistic and twart innovation. I'm sure you believe this. Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) -Andy Geir Magnusson Jr. wrote: On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - 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] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Do you have any examples of this? You aren't confusing the material I submit to the ASF JCP group from the EC with whatever you are thinking about, are you? I do not subscribe to the [EMAIL PROTECTED] list as I was informed that it would bind me in the ASF's NDA agreements with Sun. (and I don't know what the EC is in this context ... European commission?) The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. What? How would that work, logically? I mean, if the committers on the JSR are bound by an NDA, and thus can't talk to the committers on a related Apache project, how can they communicate the 'major decisions' from this committee, and inflict them on the project? Some sort of 'double-secret' commit? Add code that no one can look at? There is no project here at the ASF that isn't open for public review. Is not the specification itself a major decision? Yes the Portlet JSR has secret code that no one can look at. No one can know the goings on. Only David Taylor whom is on the committee knows what is going on and he is not permitted to talk about it. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. I'm starting to think this is a troll. Committers are promoted by their community. Sun has nothing to do with it. Further, most JSR's have nothing to do with Sun, except that Sun is financing the process management. The spec leads, in conjunction with the expert group, get copyright of the spec, dictate the license terms, etc, etc, etc. Sun has nothing to do with it, unless Sun is the spec lead. I'll be the first to say that the JCP is far from perfect, but what you are saying here doesn't make any sense. I never said it wasn't (http://www.datanation.com/fallacies/attack.htm troll). I still regard the JCP NDA agreements as detrimental to community and to innovation. Until such time as NDAs are not part of the JCP and the door is open to committers on affected projects, I will regard it as an antidote for community and innovation. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. There is no reason why a JSR can't be totally open. It's up to the spec lead, as is the license. The innovation to the platform is brought by people like you and me that decide we have an API, technology, etc, that is appropriate for addition to the platform. The innovation happens before the JSR even starts. No one proposes a JSR to do something innovative that we haven't thought of yet. They do something innovative that they have done something with already. And you do not see a dictatorial spec lead and a override by sun as being anti-community? I have not and will not sign an NDA or non-compete with Sun without substantial monetary compensation and therefore while I might innovate using the platform, I shall not be bringing my innovations to the JCP. I see no need to propose a specification or what have you via the JCP once the project has become dominant. If I had a bad standard that I wanted to push, the JCP would seem the most reasonable route to push it. So I'll say it more clearly JCP NDAs are anti-communalistic and twart innovation. I'm sure you believe this. I'm sure you have sufficient motivation not to believe that. ;-) (http://www.datanation.com/fallacies/attack.htm and one in turn) Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) So give me a count of how many do not require NDAs and where all committers on an affected project could participate on the spec committee's decision making. (You're attacking the basis. I gave an example. There is another logical fallacy that states saying well most of the 200 might not be like this and improperly shifting the burden onto the other party for refuting it.) -Andy -Andy Geir Magnusson Jr. wrote: On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects
Re: Jakarta: too many similar projects?
Andrew C. Oliver wrote: have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. My understanding is that the NDA prevent those in the JCP from sharing with the world - but AFAIK they can share it with other ASF members. If we could find a way to extend this to the whole PMC - then we can improve a bit the communication problem. Regarding the selection - I think it's up to ASF to set the policy on who will represent it in the various JCP groups. Right now it's whoever volunteers - which is reasonable. There is no ASF policy that I know about the responsibilities of those who represent the ASF in JCP - with regard to sharing the info with at least the members in the interested PMC - and I think this is a problem. As with any standard, the decision making is based on a group of people representing different interests. Apache does have a vote ( AFAIK ), just like Sun or IBM. Projects should be able to participate - and we should find a way to apply the apache meritocracy and community rules in our participation to JCP ( for example by a vote by committers who are affected or by PMCs ). In any case - your comment that the decision is made by a committee is right, and it is the way things happen in all standard organizations that I know. Even in Apache - the products are defined by a community of committers, and the decisions are made by a consensus or majority vote. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. The spec is approved by a majority vote. I don't think standard goal should be to innovate - but recognize common patterns and practices and set ground rules. As with any project - the quality of the participants and the quality of the communication has a big effect on the end result. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 11/3/03 23:40 Andrew C. Oliver [EMAIL PROTECTED] wrote: No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. The communication bonds twart collaboration which degrades innovation. I am the official Apache representative for Servlet, and in my personal experience it is quite difficult to voice some concerns I have on the direction of the with the developer community of Jakarta, because, as you said, I am not supposed to mention what goes on in the JSR lists in public whilst over in Apache land I'm not supposed to keep something private. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. Sometimes it does, sometimes it doesn't... We have example swinging both ways, the spec lead enforcing something on the JSR expert group, or in other cases, the expert group driven by the community outside forcing something on the spec lead... Most of the times, in my experience, it all comes down to how receptive the spec lead is in regards to new ideas coming from outside, and how much weight he has in his company (the JSR sponsoring company)... But my experience is too little to say what happens more often. Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? -Andy Pier Fumagalli wrote: On 11/3/03 23:40 Andrew C. Oliver [EMAIL PROTECTED] wrote: No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. The communication bonds twart collaboration which degrades innovation. I am the official Apache representative for Servlet, and in my personal experience it is quite difficult to voice some concerns I have on the direction of the with the developer community of Jakarta, because, as you said, I am not supposed to mention what goes on in the JSR lists in public whilst over in Apache land I'm not supposed to keep something private. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. Sometimes it does, sometimes it doesn't... We have example swinging both ways, the spec lead enforcing something on the JSR expert group, or in other cases, the expert group driven by the community outside forcing something on the spec lead... Most of the times, in my experience, it all comes down to how receptive the spec lead is in regards to new ideas coming from outside, and how much weight he has in his company (the JSR sponsoring company)... But my experience is too little to say what happens more often. Pier - 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: too many similar projects?
On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: Jakarta: too many similar projects?
Craig M. wrote: | Andy seems to believe that *implementing* a specification (as opposed to | creating one) is not a valid itch to be scratched if he doesn't like the | mechanism by which the specification is created. It's perfectly | reasonable for Andy to decide that for the projects he gets personally | involved in, but it seems awfully arrogant to argue that no one at Apache | should involve themselves in such an implementation project on that basis. It is straightforward to replace brand overloading with brand segmentation, including informal segmentation that is later formalized upon wide adoption. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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: too many similar projects?
Andrew C. Oliver wrote: Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. Andy: Sun doesn't control, it has one vote just like ASF or IBM. ( at least AFAIK ). If the lead is an Apache representative he can choose open mailing lists - there are few JSRs that do that. I don't know if W3C or Ecma are using only public mailing list and no NDS - but I'm pretty sure there are enough big corporations involved:-) Costin -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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: too many similar projects?
- Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:40 PM Subject: Re: Jakarta: too many similar projects? Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. Please don't feed the Trolls. -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 08:21 PM, Costin Manolache wrote: As with any standard, the decision making is based on a group of people representing different interests. Apache does have a vote ( AFAIK ), just like Sun or IBM. Projects should be able to participate - and we should find a way to apply the apache meritocracy and community rules in our participation to JCP ( for example by a vote by committers who are affected or by PMCs ). One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. The spec is approved by a majority vote. I don't think standard goal should be to innovate - but recognize common patterns and practices and set ground rules. Well - that's one way to describe it. The other way is that the JCP is how innovations are brought to the platform - the innovation was done before you tried to make a JSR. For example, Jason Hunter is running a JSR for JDOM. JDOM was done, and the benefits of the software clear, before he proposed the JSR geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 10:58 PM, Craig R. McClanahan wrote: As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. Take it a step further - how many internationally recognized standards processes will allow a single individual to propose, develop and deliver a standard? The JCP will... geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 11:40 PM, Andrew C. Oliver wrote: Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, Andy, you have pretty much the same power over a JSR as Scott McNeely does. The ASF has a vote on the EC, and Sun has a vote on the EC. Why do you think Sun has more control? take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. Or make the rules for your JSR to be open. it's up to the spec lead. geir I'm not against all standards...just NDA-based vendor baby kissing. -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Paulo Silveira [EMAIL PROTECTED] wrote: Sorry not giving a link the other time. Here is Apache voting against JSR 127 long time ago. http://www.jcp.org/en/jsr/results?id=614 You can see Apache´s comment: On 2001-05-28 Apache Software Foundation voted No with the following comment: This JSR conflicts with the Apache open source project Struts. Considering Sun's current position that JSRs may not be independently implemented under an open source license, we see little value in recreating a technology in a closed environment that is already available in an open environment. I would simply like to point out WHO is the specification lead of JSR-127 (see http://www.jcp.org/en/jsr/detail?id=127), and who was the initial author of Struts (see http://jakarta.apache.org/struts/volunteers.html)... Apache's concerns were Considering Sun's current position that JSRs may not be independently implemented under an open source license [...], and I'll let you make 1 + 1 here... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta: too many similar projects?
Why create something in official Java APIs/Products when there is allready a good OSS alternative. To standardise it. Why is OSS any different? Exactly! So why bother standardizing it via Sun. If there is a ubiquitous Apache standard already, then there is NO need for a Sun standard. Personally I think the danger is, as Andy pointed out, that Sun including a lot of functionality in the core distribution of Java JSE or in JEE limits the ability of third parties to develop solutions, in a way very similar to M$'s inclusion of extended functionality in the basic Windows OS installation. Standards should not be taken to mean product most widely used or the product officially supported they are something else. IMO standards are, and should be, benchmarks against which people can compare their work and say either it does or it does not support standard x,y or z. Standards compliance can be a goal of any software project. Standards compliance as a goal of un-related projects results in the kind of interoperability that is fundamental to the character of the internet. Open Source has standards as a cornerstone because it allows loosely coordinated groups to produce interoperable systems simply by supporting common, published, contracts. Sun's use of JSR's to add core functionality, as far as I can see, goes way beyond the standardization of contracts to include implementations, and these implementations are often bundled with Java in one form or another. The result is that if you are interested in the contract you don't need to go elsewhere to find software implementing it, its right there already, and its free, so why bother? As far as I can see Apache's position in the JSR review defends the right of third parties to be allowed to implement contracts approved by JSR and adopted by Sun on an equal footing with the JSR's participants and cash rich commercial organisations. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Danny Angus wrote: Why create something in official Java APIs/Products when there is allready a good OSS alternative. To standardise it. Why is OSS any different? Exactly! So why bother standardizing it via Sun. If there is a ubiquitous Apache standard already, then there is NO need for a Sun standard. Personally I think the danger is, as Andy pointed out, that Sun including a lot of functionality in the core distribution of Java JSE or in JEE limits the ability of third parties to develop solutions, in a way very similar to M$'s inclusion of extended functionality in the basic Windows OS installation. *and* bloats Java. I have a JAXP and TRAX implementation in Sun's JRE, that I need to override, because it does not work with most projects, for instance. I have the whole Swing, even if I don't use it in my tomcat VMs or with ant/maven... Those could be pluggable (as JAXP or TRAX, or JAAS, or even parts of JDBC, used to be). Standards should not be taken to mean product most widely used or the product officially supported they are something else. IMO standards are, and should be, benchmarks against which people can compare their work and say either it does or it does not support standard x,y or z. Standards compliance can be a goal of any software project. Standards compliance as a goal of un-related projects results in the kind of interoperability that is fundamental to the character of the internet. Open Source has standards as a cornerstone because it allows loosely coordinated groups to produce interoperable systems simply by supporting common, published, contracts. A wholehearted +1. Sun's use of JSR's to add core functionality, as far as I can see, goes way beyond the standardization of contracts to include implementations, and these implementations are often bundled with Java in one form or another. The result is that if you are interested in the contract you don't need to go elsewhere to find software implementing it, its right there already, and its free, so why bother? As far as I can see Apache's position in the JSR review defends the right of third parties to be allowed to implement contracts approved by JSR and adopted by Sun on an equal footing with the JSR's participants and cash rich commercial organisations. While Apache is taking advantage of this with Tomcat and other projects, I'm not sure it is a good thing. and then Andrew C. Oliver wrote: Therefore, supporting JSRs where there are already good dominant Apache projects is against Apache's interest. You either get sidestepped like the JSP vs Velocity thing or you move the decision making process into Sun which is apt to happen with Jetspeed. I don't think the Original proposal for the Portlet API is bad (I don't know yet the outcome of the process). It was a light weight API, modelled after the Servlet API, and offered possibilities for use. But the whole discussion has been held behind doors. And the process has frozen possible evolutions of the project in the wait (this is possibly a tactical mistake on our part, coupled with one of the main developers being forced to a very difficult position under NDA). Also, like Danny wrote, the fact that the JSR comes with a RI coming from the outside and for free, brings a danger to kill possible alternative designs. All of this kills cyberdiversity. I imagine that it has helped a lot to promote java as a programming platform and make it feature complete, but the times are coming where it is no longer a good policy. Just Random Thoughts Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Paulo Silveira wrote: Sorry not giving a link the other time. Here is Apache voting against JSR 127 long time ago. In such case we could (should) understand ASF position. Why create something in official Java APIs/Products when there is allready a good OSS alternative. It still a shame that Sun didn't selected log4j for 1.4. BTW, having multiple OSS competitors projects is a good stimulation and could result in a later merge (see TC3/TC4 = TC5). Diversity is great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
I can understand it if the ASF were worried that a JSR would put the existence of the OSS project in doubt, due to the legalities of an OSS project not being able to be a JSR implementation in some cases, but not to protect their product. Why not? What is the point of having a JSR which requires useless changes in an OSS project just to support the JSR? Opensource standards are DEFACTO standards. Economics works to their benefit. JSRs take the decision making process AWAY from the community and puts it in the hands of folks whom are willing to sign their brains away via NDAs. You cannot have a community if members are under NDA. You also can't have a meritocratic community if some members get to make specification decisions and others don't based strictly on who has signed their brain away to Sun. Therefore, supporting JSRs where there are already good dominant Apache projects is against Apache's interest. You either get sidestepped like the JSP vs Velocity thing or you move the decision making process into Sun which is apt to happen with Jetspeed. I guess it depends on whether you think you're here to work in a community and help yourself or if you're here to stroke Sun. Why create something in official Java APIs/Products when there is allready a good OSS alternative. To standardise it. Why is OSS any different? Exactly! So why bother standardizing it via Sun. If there is a ubiquitous Apache standard already, then there is NO need for a Sun standard. Why create an official Java API when there is an already good commercial product? This is irrelevant to the discussion. It still a shame that Sun didn't selected log4j for 1.4. Because it was quite arguably the de facto standard by the point the JSR was announced. And how does supporting Sun's JSR for logging help Apache? Especially log4j? Diversity is great. And forcing a lack of diversity merely prevents one set of possibilities happening. So +1 to diversity. And JSRs limit diversity ;-) (you don't always want diversity, but note that standards are a limit on diversity) -Andy 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]
Re: Jakarta: too many similar projects?
On Wednesday, March 5, 2003, at 09:00 AM, Paulo Silveira wrote: On 2001-05-28 Apache Software Foundation voted No with the following comment: This JSR conflicts with the Apache open source project Struts. Considering Sun's current position that JSRs may not be independently implemented under an open source license, we see little value in recreating a technology in a closed environment that is already available in an open environment. Sun's position has changed since then :) -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Its Sun's JSR, let them impelment it. Why does Apache have to play lap dog to Sun? Who wants to spend their free time working on what are usually lousy specifications that they have no input into? JSRs usually come with community problems such as Non-Disclosure agreements which put some members of any project created around one at a siginificant disadvantage. Secondly, if some members go off to the specification committee to make all of the decisions and the others are left just to do what they say, how is that consensus based decision making? Overall, it seems that JSRs make BAD apache projects. Secondly, Jakarta/Apache isn't about providing one-size-fits-all solutions. Its about supporting community based development. Meaning projects that wish to develop via community-based development do not belong here. However projects that DO wish to develop through community-based development might belong here. This is regardless of whether there is a similar project. Turbine/Velocity and friends is a totally different approach than Struts/JSP (in part because JSP completely and totatlly sucks, even struts is trying to support other presentation layers). Tapestry is totally different then either of those. I could see some situations where I might use Tapestry. I can see other situations where it would totally suck. Hell I can even find some situations where I might use Struts/JSP (though I'd be more inclined if the XML stuff were incorporated and not forked off in another project). Choice is good. Its also irrelevant to the issue (community-based meritocratic development) From a user perspective coming from commercial software, I can see where this would be confusing. Why would a company put out products that compete with each other? Well we're not limited by such thinking. Live Well, Andy Howard M. Lewis Ship wrote: I don't know any of this stuff about Apache refusing a JSR. As I'm seeing it from my end, Jakarta looks to centralize good technologies, but only if a good community of developers and users are part of the deal. I suspect that this rejecting a JSR may come down to something like Sun trying to dump half-working code in Jakarta's lap and expecting folks to rise up and make it work. In terms of web apps and MVC ... well, everyone has their own approach and own definition of MVC, or pull-MVC, or whatever. I do some of my work in Struts (at my day job), but obviously, love Tapestry. Anyway, saying something is a web app framework doesn't really say too much, especially under the shadow of the Servlet API. You could just as easily clump Java, Objective-C and C++ as C-like languages and complain that people should chose one and back it. Aint gonna happen -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry -Original Message- From: Paulo Eduardo Azevedo Silveira [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:07 PM To: Jakarta General List Subject: Jakarta: too many similar projects? Ok, maybe this is the right place and time. I ve seen Howard talking about Tapestry, then I decided to take a better look at it. At the first look, it seems as a small front controller and a template engine. What I cant understand is why does Jakarta keep getting new M or V or C subprojects that almost compete with each other, instead concentrating forces in a single one. In JCP I ve seen Apache refusing a JSR (JSF if I am not wrong) because it would go directly against Struts. But Jakarta is doing this to itself! I can understand having OJB even with Torque, its very different and it will be JDO. What I dont get is Tapestry AND Velocity AND EL AND Struts taglib AND maybe something that I dont know. Sorry if I didnt get what is the real Jakarta proposal. And Howard, I am really not complaining about Tapestry, it is just one example (I reallylike the idea of removing all links and URLs from templates). I really dont want a flame. thanks Paulo On Tue, 4 Mar 2003 18:41:56 -0500, Howard M. Lewis Ship [EMAIL PROTECTED] escreveu : De: Howard M. Lewis Ship [EMAIL PROTECTED] Data: Tue, 4 Mar 2003 18:41:56 -0500 Para: 'Jakarta General List' [EMAIL PROTECTED] Assunto: RE: Jakarta-POI 1.10.0-dev released I'm looking for a bit of advice. People keep asking me how many people are using Tapestry ... and I honestly have no idea. Insufficient feedback. Do you have a way of determining the user base of POI? Any guidelines based on downloads? -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulo Silveira ICQ 5142673 Grupo de Usuários Java http://www.guj.com.br/
RE: Jakarta: too many similar projects?
I don't know any of this stuff about Apache refusing a JSR. As I'm seeing it from my end, Jakarta looks to centralize good technologies, but only if a good community of developers and users are part of the deal. I suspect that this rejecting a JSR may come down to something like Sun trying to dump half-working code in Jakarta's lap and expecting folks to rise up and make it work. In terms of web apps and MVC ... well, everyone has their own approach and own definition of MVC, or pull-MVC, or whatever. I do some of my work in Struts (at my day job), but obviously, love Tapestry. Anyway, saying something is a web app framework doesn't really say too much, especially under the shadow of the Servlet API. You could just as easily clump Java, Objective-C and C++ as C-like languages and complain that people should chose one and back it. Aint gonna happen -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry -Original Message- From: Paulo Eduardo Azevedo Silveira [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:07 PM To: Jakarta General List Subject: Jakarta: too many similar projects? Ok, maybe this is the right place and time. I ve seen Howard talking about Tapestry, then I decided to take a better look at it. At the first look, it seems as a small front controller and a template engine. What I cant understand is why does Jakarta keep getting new M or V or C subprojects that almost compete with each other, instead concentrating forces in a single one. In JCP I ve seen Apache refusing a JSR (JSF if I am not wrong) because it would go directly against Struts. But Jakarta is doing this to itself! I can understand having OJB even with Torque, its very different and it will be JDO. What I dont get is Tapestry AND Velocity AND EL AND Struts taglib AND maybe something that I dont know. Sorry if I didnt get what is the real Jakarta proposal. And Howard, I am really not complaining about Tapestry, it is just one example (I reallylike the idea of removing all links and URLs from templates). I really dont want a flame. thanks Paulo On Tue, 4 Mar 2003 18:41:56 -0500, Howard M. Lewis Ship [EMAIL PROTECTED] escreveu : De: Howard M. Lewis Ship [EMAIL PROTECTED] Data: Tue, 4 Mar 2003 18:41:56 -0500 Para: 'Jakarta General List' [EMAIL PROTECTED] Assunto: RE: Jakarta-POI 1.10.0-dev released I'm looking for a bit of advice. People keep asking me how many people are using Tapestry ... and I honestly have no idea. Insufficient feedback. Do you have a way of determining the user base of POI? Any guidelines based on downloads? -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulo Silveira ICQ 5142673 Grupo de Usuários Java http://www.guj.com.br/ - 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]
