Totally agree. Though its worth mentioning that the Servlet, JSP & JSTL JSRs all have their their reference implementations developed at Jakarta (Tomcat & jakarta-taglibs) so there's CVS, a public archived email list and bugzilla. I do hope that these JSRs start a trend that most/all JSRs open source the RI and TCK. It just makes so much sense. I think Sun as a company still have a lot to learn about open source; though there's plenty of good people at Sun who are showing the way.
I'd prefer all EG communication to be open on a public forum though I understand that sometimes privacy enables some companies to participate do to IP issues. James ----- Original Message ----- From: "Daniel F. Savarese" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 21, 2002 7:12 PM Subject: [OT] JCP rant > > Somebody asked on the axi-user mailing list why they should use Axis > instead of JAXM. I offered some comments, but tried not to stray > too off topic. In light of a recent JCP-related thread, I thought > there might not be any objections on general@jakarta if I vented for > a minute. > > When you use JAXM, you'll run up against all sorts of limitations and > the best you can do is send a suggestion/comment to an email address. > With Axis, or any Apache project, if you run up against a limitation, > you can discuss it on a mailing list and submit a patch. > Hypothesis: JCP JSRs that have more frequent feedback iteration cycles and > provide source code tend to produce better results than those with fewer > feedback cycles. I'll use JAXM and JAX-RPC as examples. JAXM > had no mailing list for developer discussion/feedback as it was being > designed/developed with only the usual JCP JSR comment address. JAX-RPC > has a jaxrpc-interest mailing list that has helped the spec evolve into > something more likely to be useful to developers. With something as > simple as a mailing list a JCP JSR can gather much better requirements. > However, neither JSR provided source for their reference implementations, > making debugging and patch submission an impossibility. > > The problem with the JCP is not merely the licensing. It is also the > basic JSR procedures. The objective of a new API is to meet some set > of developer requirements in a particular application domain. If you > don't consult with your users, the target developer group, you probably > won't develop a useful result. JSRs would produce better results if run a > little more like Apache projects, with more opportunity for user feedback > in an open forum to mold the ultimate result into something useful. > > daniel > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
