Re: Jakarta Scope
--- Henri Yandell [EMAIL PROTECTED] wrote: I think our scope is: *** Components that are, a) written in and/or for the Java environment b) too small in the long-term to be their own independent communities *** This is what I put on the wiki a while back (framed in website-friendly language not scope-friendly language): Jakarta provides a diverse set of Java-based components which aim to make day-to-day development easier. The focus is on reusable, small-scale, single-purpose libraries that can be used directly by your application or by larger frameworks. The key points were: - Java-based - reusable - small-scale - single-purpose - libraries Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Scope
Hi, I agree with this. Jakarta's niche should be to provide a central repository of Java-based components and libraries filling a variety of functions. When I got started with Java web dev about 5 years ago I evaluated every component of Jakarata to see if it could help my startup. Made a big difference to have a central resource of useful but lesser-known libraries, all under a business-friendly license. As a developer, I also appreciate Jakarta's role in providing an organization framework for small libraries that fit well under the Apache umbrella but may not be worth an individual's effort to run as a TLP. Apache provides a lot of advantages for a project, there's no reason to force people to go use Sourceforge for small libraries. Historically, Jakarta has included more significant applications (like Tomcat) but I don't see that as necessary. I read about big open source apps in books, magazines, articles and go directly to their web site. Tomcat, Subversion, Hibernate, and so forth. An index of such items is mildly useful but not critical. The trend of moving these to the broader Apache site is the right direction. WILL On 4/11/06, Stephen Colebourne [EMAIL PROTECTED] wrote: --- Henri Yandell [EMAIL PROTECTED] wrote: I think our scope is: *** Components that are, a) written in and/or for the Java environment b) too small in the long-term to be their own independent communities *** This is what I put on the wiki a while back (framed in website-friendly language not scope-friendly language): Jakarta provides a diverse set of Java-based components which aim to make day-to-day development easier. The focus is on reusable, small-scale, single-purpose libraries that can be used directly by your application or by larger frameworks. The key points were: - Java-based - reusable - small-scale - single-purpose - libraries Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Scope
At jakarta.apache.org we say: 1/ The Jakarta Project offers a diverse set of open source Java solutions and is a part of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license. 2/ Our charter (http://jakarta.apache.org/site/management.html) says nothing about scope. The Commons charter says: 3/ Apache-Java and Jakarta originally hosted product-based subprojects, consisting of one major deliverable. The Java language however is package-based, and most of these products have many useful utilities. Some products are beginning to break these out so that they can be used independently. A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. In terms of scope restriction, all three are pretty empty. I think our scope is: *** Components that are, a) written in and/or for the Java environment b) too small in the long-term to be their own independent communities *** Which isn't much, but I can't think of a lot more to add. It's really the same scope for both Jakarta and Commons - the only difference is the concept of size. Currently in Commons, too small means too small to be a Jakarta subproject, while in Jakarta it means too small to be an Apache TLP. In the direction I suggest we should take, too small means the latter - too small to be an Apache TLP. That still leaves Incubator vs Sandbox issues. Commons Math is one such example - in scope it could be an entire open source foundation. We've occasionally talked about it becoming a math.apache.org someday, but currently it's only really just starting to approach the feel of a current Jakarta subproject in size (same number of lines of code as bcel for example). How do you draw the line on potential long-term scope vs likely long-term scope? From memory, you talk about it on the mailing list until everyone involved in the conversation is happy with the idea. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
