On Saturday, June 7, 2003, at 04:44 PM, Justin Erenkrantz wrote:
<snip>
Jakarta has a lot of things in its sandbox (and so does XML) that I would consider violates its original charter. But, that doesn't work for all ASF projects and their PMCs. -- justin
the problem is interpreting what server-side solutions really means. if jakarta had been charged with creating services then a lot of items in jakarta (as well as the sandbox) would be out of scope. server-side java solutions is a very wide area of scope - most java developers spend of their time working on server-side java.
jakarta has had a tough time in drawing a line - but these issues have been debated at length. jakarta has been very conservative in accepting new subprojects - it's been very hard to get a new sub-project accepted. but it's very hard to tell someone that a particular idea violates the charter when they come up with a compelling argument why developers working on server-side java need it. so in the end, the interpretation settle on was pretty much the only logical and reasonable one - that any code for which a compelling argument could be made for usage in server-side java development was in scope.
unlike other languages, java lacks a solid body of library code. in order to develop server-side solutions, a large quantity of utility code has had to be developed from scratch. it's very hard to see how code is in-scope when it's distributed as part of an existing subproject but out of scope when it's distributed by itself. for example, digester originated in the tomcat code base. it's hard to see how the same code can be in-scope when it's in tomcat and out-of-scope when it's in jakarta-commons.
when viewed from the perspective of the working interpretation of scope commonly used by jakarta, i've taken a quick look and all the components i can see fall within the working definition of scope used by jakarta.
- robert
