Subproject Proposals Not Every Software Product Is Suited for Life at Jakarta

Total Page:16

File Type:pdf, Size:1020Kb

Subproject Proposals Not Every Software Product Is Suited for Life at Jakarta Subproject Proposals Not every software product is suited for life at Jakarta. Before proposing a new subproject, it is important to read this document carefully and determine whether your product is a good fit. Before Reading... The Apache Software Foundation has established a project for the acceptance of new codebases and for the incubation, named Apache Incubator Project on October, 2002. If you, who are thinking of donating code and starting a project, have some contributions to make for an existing Jakarta sub-project, work with that community via the mailing lists. If you have any idea about something new to start, you might have two options. If appropriate to the Jakarta Commons, you might try to ignite a discussion about your ideas there. If it's larger and far enough along in development, the Apache Incubator Project would be a good place to discuss. Criteria Here are some best practices that we will expect to find in a successful proposal. This is not a checklist, but guidelines to help communicate what is expected of a Jakarta subproject. Meritocracy. Before submitting a proposal, be sure to study the guidelines that govern Jakarta subprojects. These guidelines explain our system of Meritocracy, which is the core of the Jakarta Project. If the product developers do not wish to adopt this system, then they should not donate their code to the Project, and should look elsewhere for hosting. Community. Jakarta is a Project of the Apache Software Foundation. A prime purpose of the ASF is to ensure that the Apache projects continue to exist beyond the participation of individual volunteers. Accordingly, a prime criteria required of any new subproject is that it already enjoys -- or has a high potential for attracting -- an active community of developers and users. Proposals for non-established products have been accepted, most often when the proposal was tendered by experienced open source developers, who understand what it means to build a community. A design document, developer and user documentation, example code, and a working implementation all help to increase the likelihood of acceptance. Well- From jakarta.apache.org/site/newproject.html 1 4 August 2004 documented products tend to build stronger communities than products that rely source code and JavaDocs alone. Core Developers. To considered, a product must have at least 3 active developers who are already involved with the codebase. This is an absolute minimum, and it is helpful for there to more than three developers. It is very helpful for at least one of the developers making the proposal to already be active in a Jakarta subproject or other open source initiative. At Jakarta, the core developers of a product (the Committers) manage the codebases and make the day-to-day development decisions. We are only interested in products that can guided by their own development communities. Jakarta provides the infrastructure, and some essential guidelines, but the Committers must take responsibility for developing and releasing their own product. Alignment with existing Apache subprojects. Products that are already used by existing subprojects make attractive candidates, since bringing such a codebase into the Apache fold tends to benefit both communities. Products with dependancies on existing Apache products are also attractive for the same reason. Scope. Jakarta products are generally server-side software solutions written for the Java platform. Proposals for products outside this venue will have greater difficulty in being accepted. Warning Signs These are anti-patterns that we have found detrimental to the success of a proposal. Some of these are lesson learned from the school of hard-knocks, others are taken from proposals which have been rejected in the past. All will raise a red flag, making it unlikely that a proposal will be accepted. Orphaned products. Products which have lost their corporate sponsor (for whatever reason) do not make good candidates. These products will lack a development community and won't have the support needed to succeed under the Jakarta umbrella. For example, we have seen proposals that contain paragraphs like this: FooProduct is currently a production quality product, and in fact is being used a live website. It was developed as a product by FooCompany, with the intention that we would sell it. However, due to various economic factors such as the decline in FooProduct's intended market and the recent difficulties in obtaining venture capital, we have decided that at this time it is not feasible for us to continue in that direction. The alleged quality of a product is not the prime criteria. To be accepted, we must believe that a product will attract volunteers to extend and maintain it over the long term. A product like this, arriving with no volunteer developers or open From jakarta.apache.org/site/newproject.html 2 4 August 2004 source community, does not further Jakarta's mission, and would not be accepted. We generally recommend that an orphaned product start with an independent host, and consider making a proposal after it has started to build a community. Inexperience with open source. We often receive proposals that start with "We will open our software if you choose to accept it." This is the wrong way to approach the proposal process. A closed source project does not have an open community, and so we have no way to tell if the developers can work in an open source environment. Products that have lived on their own and have started to develop their own community, have a much better chance of being accepted. If the product's developers have not worked with open source before, it is recommended that they spend some time contributing to an existing open source project before trying to manage one of their own. Since Jakarta subprojects are managed by their own Committers, it is important that a new product supported by people who understand how open source works. Homogenous developers. Apache communities attract developers with diverse backgrounds. Products with a tightly-knit team of developers may have difficulty shepherding new developers into the fold. It is vital that we believe the developers will discuss development issues openly with the community, and not make decisions behind closed doors. We are especially wary of products with developers who all share a common employer or geographic location. Reliance on salaried developers. Jakarta has strong ties to the business community. Many of our developers are encouraged by their employers to work open source projects as part of their regular job. We feel that this is a Good Thing, and corporations should be entitled to contribute to open source, same as anyone else. However, we are wary of products which rely strongly on developers who only work on open source products when they are paid to do so. A product at Jakarta must continue to exist beyond the participation of individual volunteers. We believe the best indicator of success is when developers volunteer their own time to work open source projects. No ties to other Apache products. Products without a tie to any existing Apache product, and that have strong dependencies on alternatives to Apache products, do not make good candidates. Many Apache products are related through common licenses, technologies, and through their volunteers. Products without licensing, technology, or volunteers in common will have trouble attracting a strong community. A fascination with the Apache brand. The Apache Software License is quite liberal and allows for the code to used in commercial products. This can induce people to donate a commercial codebase to the ASF, allow it developed as open source for a time, and then convert it back to commercial use. While this would legal under the Apache Software License, we are wary of proposals that seem to be more interested in exposure than community. From jakarta.apache.org/site/newproject.html 3 4 August 2004 Subproject Alternatives If your product is a JSP tag library, you should contact the Jakarta Taglibs subproject before proposing a new subproject. Other subprojects at Jakarta also host useful components within their own codebases. Jakarta Commons and Jakarta Turbine all have significant sub- systems which also could be products in their own right. See the Jakarta home page for a description of all our subprojects. The Avalon Project, TLP (Top Level Project) of Apache.org, also has significant sub-system. If your product might a good fit within an existing subproject, contact the subproject's committers through their mailing list. If your product is XML related, be sure to also visit the Apache XML Project or Apache Cocoon Project to see if it would be a good fit there. If your product is Web Service related, be sure to also visit the Apache WebService Project to see if it would be a good fit there. Who Decides Final acceptance is based the rules defined in the Project Management Committee Bylaws which state that "Creation of a new subproject requires approval by 3/4 vote of the PMC." The proposal for a new subproject must submitted to the Jakarta General mailing list, where the PMC conducts business. All discussion regarding the proposal will occur the General list, including the final vote. From jakarta.apache.org/site/newproject.html 4 4 August 2004 .
Recommended publications
  • Configuring & Using Apache Tomcat 4 a Tutorial on Installing and Using
    Configuring & Using Apache Tomcat 4 A Tutorial on Installing and Using Tomcat for Servlet and JSP Development Taken from Using-Tomcat-4 found on http://courses.coreservlets.com Following is a summary of installing and configuring Apache Tomcat 4 for use as a standalone Web server that supports servlets 2.3 and JSP 1.2. Integrating Tomcat as a plugin within the regular Apache server or a commercial Web server is more complicated (for details, see http://jakarta.apache.org/tomcat/tomcat-4.0-doc/). Integrating Tomcat with a regular Web server is valuable for a deployment scenario, but my goal here is to show how to use Tomcat as a development server on your desktop. Regardless of what deployment server you use, you'll want a standalone server on your desktop to use for development. (Note: Tomcat is sometimes referred to as Jakarta Tomcat since the Apache Java effort is known as "The Jakarta Project"). The examples here assume you are using Windows, but they can be easily adapted for Solaris, Linux, and other versions of Unix. I've gotten reports of successful use on MacOS X, but don't know the setup details. Except when I refer to specific Windows paths (e.g., C:\blah\blah), I use URL-style forward slashes for path separators (e.g., install_dir/webapps/ROOT). Adapt as necessary. The information here is adapted from More Servlets and JavaServer Pages from Sun Microsystems Press. For the book table of contents, index, source code, etc., please see http://www.moreservlets.com/. For information on servlet and JSP training courses (either at public venues or on-site at your company), please see http://courses.coreservlets.com.
    [Show full text]
  • Version Control: a Case Study in the Challenges and Opportunities For
    Version Control: A Case Study in the Challenges and Opportunities for Open Source Software Development (Position Paper for 2nd Workshop on Open Source Software Engineering) Mark C. Chu-Carroll, David Shields and Jim Wright {mcc,shields,jwright}@watson.ibm.com IBM T. J. Watson Research Center 19 Skyline Drive, Hawthorne, NY 10522 Abstract variants of the kernel source tree [2] , and problems coordinating updates and the addition of The growth of the worldwide open source new features have been reported, as noted in a development effort, driven in part by the recent discussion of Virtual Memory Managers [3] . entrance of large corporations into the open source Torvalds has recognized these problems [4] , and arena, offers new opportunities to improve the recently reported that he is using the Bitkeeper software engineering tools available for that effort. version control system [5, 6, 7] . Indeed, the increasing difficulty of managing large Compiling the Linux kernel itself presents a open source projects, as well as that of integrating complicated configuration problem, recently related efforts into new programming addressed by Eric Raymond, the author of CML2 environments, represents a challenge that must be [8]," a configuration system ... that handles build- met if the rapid growth of open source software is option selection for Linux kernels" that is to continue. This position paper addresses these "scheduled to be integrated into the Linux kernel issues in the context of software version control. source tree between 2.5.1 and 2.5.2." (Text in quotes, here and later on, is from the referenced Version Control and the Linux Kernel web sites.) CML2 is written in Python and, according to the CML2 Announcement [9]: "For The Linux kernel, perhaps the most crucial piece of those of you who grumbled about adding Python to open source software, represents an interesting the build-tools set, Linux has uttered a ukase: example in that the kernel developers use a CML2's reliance on Python is not an issue" (See primitive form of version control.
    [Show full text]
  • A Test Suite Generator for Struts Based Applications Gregory M
    UNF Digital Commons UNF Graduate Theses and Dissertations Student Scholarship 2004 A Test Suite Generator For Struts Based Applications Gregory M. Jackson University of North Florida Suggested Citation Jackson, Gregory M., "A Test Suite Generator For Struts Based Applications" (2004). UNF Graduate Theses and Dissertations. 294. https://digitalcommons.unf.edu/etd/294 This Master's Thesis is brought to you for free and open access by the Student Scholarship at UNF Digital Commons. It has been accepted for inclusion in UNF Graduate Theses and Dissertations by an authorized administrator of UNF Digital Commons. For more information, please contact Digital Projects. © 2004 All Rights Reserved A TEST SUITE GENERATOR FOR STRUTS BASED APPLICATIONS By Gregory M. Jackson A project submitted to the Department of Computer and Information Sciences in partial fulfillment of the requirement for the degree of Master of Science in Computer and Information Sciences UNIVERSITY OF NORTH FLORIDA DEPARTMENT OF COMPUTER AND INFORMATION SCIENCES April2004 Copyright(©) 2004 by Gregory M. Jackson All rights reserved. Reproduction in whole or in part in any form requires the prior written permission of Gregory M. Jackson or designated representatives. 11 APPROVAL BY THE PROJECT COMMITTEE The project "A Test Suite Generator for Struts Based Applications" submitted by Gregory M. Jackson in partial fulfillment of the requirements for the degree of Master of Science in Computer and Information Sciences has been approved by the Project Committee: Sentence Deleted Arturo Sanch , Ph.D. Project Director Sentence Deleted Sentence Deleted Charles Winton, Ph.D. Graduate Director 111 ACKNOWLEDGEMENTS This project is dedicated to my father, Marshall Jackson, who always pushed me to work hard on everything I do and showed me that if I put my mind to it, anything is possible.
    [Show full text]
  • P6 EPPM Licensing Information User Manual 16 R2
    P6 EPPM Licensing Information User Manual 16 R2 September 2016 Contents Introduction............................................................................................. 7 Licensed Products, Restricted Use Licenses, and Prerequisite Products ................... 7 Primavera P6 Enterprise Project Portfolio Management License ................................. 7 Primavera P6 Enterprise Project Portfolio Management Web Services License ................ 9 Primavera P6 Progress Reporter ..................................................................... 10 Third Party Notices and/or Licenses .............................................................. 11 AndroidSwipeLayout ................................................................................... 11 aopalliance ............................................................................................. 11 Apache Chemistry OpenCMIS ......................................................................... 11 Apache Commons Net ................................................................................. 12 Apache Derby........................................................................................... 12 Apache ECS ............................................................................................. 12 Apache Jakarta Commons Library ................................................................... 12 Apache Tiles ............................................................................................ 12 Apache Xerces .........................................................................................
    [Show full text]
  • Entitlement Control Message Generator
    Open Source Used In ECMG 4.5.3 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-156819513 Open Source Used In ECMG 4.5.3 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-156819513 Contents 1.1 ACE+TAO 5.5.10 + 1.5.10 1.1.1 Available under license 1.2 Apache Commons Codec 1.3. 1.2.1 Available under license 1.3 Apache Commons Lib Apache 2.0 1.3.1 Available under license 1.4 Apache Jakarta Commons Configuration 1.9 1.4.1 Available under license 1.5 Apache Jakarta Commons DBCP 1.4 1.5.1 Available under license 1.6 Apache Jakarta Commons Lang 3.1 1.6.1 Available under license 1.7 Apache Log4j 1.2.16 1.7.1 Available under license 1.8 apache-ant_within-cglib 1.6.5 1.8.1 Available under license 1.9 apache-log4j 1.2.15 1.9.1 Available under license 1.10 apache-log4j 1.2.15 :DUPLICATE 1.10.1 Available under license 1.11 args4j 2.0.12 1.11.1 Available under license 1.12 asm-all-3.3.1_within-cglib 3.3.1 1.12.1 Available under license 1.13 bcprov-jdk16
    [Show full text]
  • Oreilly.Com/Catalog/Jakarta
    Programming Jakarta Struts By Chuck Cavaness Table of Contents Preface The road to successful web applications is paved with the sweat and heartache of the many who came before us. The idea of taking a rich client application and allowing it to execute over the Internet was a great leap of faith, and maybe just a little shortsighted. By "web applications," I don't mean small, trivial applications that accept a form or two of input and push it into a database; I mean large applications that cross several tiers, use many different technologies, and cover the spectrum of analysis and design-pattern uses. The design and construction of these types of applications push developers to the limit of what's logically and physically possible. Myriad solutions have been thrown at the problems these applications present. Some of the solutions stuck, and some did not—and when a solution didn't serve the needs of the users, it was obvious. But as with human evolution, the valuable characteristics eventually were passed on, and the characteristics that failed to serve their intended purposes fell by the wayside. The user interface (UI) in Smalltalk-80™ was designed around the Model-View-Controller (MVC) framework. Over time, this framework has been adopted as a classic design pattern and used in many different scenarios. Other UI frameworks, such as the one written for Java™ Swing, use similar concepts. The architects of the JavaServer Pages™ (JSP) specification formally introduced the abstract idea of two types of models for web-based solutions: Model 1 and Model 2.
    [Show full text]
  • Apache Tomcat Overview
    A sample Training Module from our course WELL HOUSE CONSULTANTS LTD 404, The Spa • Melksham, Wiltshire SN12 6QL • United Kingdom PHONE: 01225 708225 • FACSIMLE 01225 707126 • EMAIL: [email protected] © 2004 Well House Consultants Ltd., all rights reserved • written by Graham J. Ellis 23 Tomcat Overview Programs need an environment in which to run within a host computer. Sometimes the operating system is sufficient to provide the environment, but at other times a more sophisticated container is needed. Tomcat is a container that’s used to provide an environment for Java code running on a web server. What is Tomcat? . 346 The structure of Tomcat. 347 Well House Consultants Samples Tomcat Overview 345 A651 If you’re going to be running Java code on your web server (either in the form of Servlets or Java Server Pages), then you’ll need appropriate software for the purpose. An operating system isn’t enough as it won’t provide your Java Runtime Environ- ment, nor your web server, nor the tools to tie Java to the web. You’ll need a container in which to run your Servlets and JSPs, and the most commonly used container is Tomcat. 23.1 What is Tomcat? Visit http://jakarta.apache.org/tomcat/index.html and you read: "Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifi- cations are developed by Sun under the Java Community Process." And... "Tomcat is developed in an open and participatory environment and released under the Apache Software License.
    [Show full text]
  • Jakarta EE: Building Microservices JAVA EE with Java EE’S Successor
    Search Java Magazine Menu Topics Issues Downloads Subscribe Jakarta EE: Building Microservices JAVA EE with Java EE’s Successor How We Got to Jakarta EE Jakarta EE: Building Microservices New Governance Process with Java EE’s Successor Getting Started with Jakarta EE A first look at using the emerging enterprise Building the Sports Roster Application Java release for building microservices Setting Up the Environment by Josh Juneau Obtaining Projects for Use Within Developers have taken many approaches over the years to developing Services web and enterprise applications on the Java platform. At the inception of Developing the Services the JVM, the groundbreaking servlet technology was introduced in an effort to bring dynamic content to web applications, and technology such Deployment Options and as applets provided a way to deliver rich internet applications to a user’s Configurations desktop. Over time, developers created easier and more intuitive ways to work with servlets via frameworks such as JavaServer Pages (JSPs) and Roadmap Apache Struts. Built on top of servlet technology, these solutions enabled developers to focus more on the front end than on boilerplate code. The J2EE platform was introduced in 1999, providing a handful of APIs for the creation of enterprise-based applications. The APIs included JDBC, Enterprise JavaBeans (EJB), JSPs, and Java Message Service (JMS), to name a few. In the early era, J2EE was complex, because there were many configurations that needed to be made and the logic was difficult to follow. Configuration made the platform difficult to use. As the years went on, J2EE evolved to include more APIs and the complexity level decreased.
    [Show full text]
  • Table of Contents
    Links Table of contents 1 Multimedia................................................................................................................... 2 2 hvanbelle-sites.............................................................................................................. 2 3 Search........................................................................................................................... 2 4 News.............................................................................................................................3 5 Programming................................................................................................................ 3 5.1 General.....................................................................................................................3 5.2 Ruby.........................................................................................................................3 5.3 Perl........................................................................................................................... 3 5.4 Java.......................................................................................................................... 3 5.5 Java Netbeans...........................................................................................................4 5.6 Apache..................................................................................................................... 4 5.7 WebSphere...............................................................................................................4
    [Show full text]
  • P6 EPPM Licensing Information User Manual Version 17
    P6 EPPM Licensing Information User Manual Version 17 September 2017 Contents Introduction............................................................................................. 7 Licensed Products, Restricted Use Licenses, and Prerequisite Products ................... 7 Primavera P6 Enterprise Project Portfolio Management Cloud Service .......................... 7 Primavera P6 Standard Project Portfolio Management Cloud Service ........................... 7 Primavera P6 Progress Reporter Cloud Service ...................................................... 8 Primavera P6 Enterprise Project Portfolio Management Web Services Cloud Service ......... 8 Primavera Virtual Desktop Cloud Service ............................................................ 8 Primavera P6 Enterprise Project Portfolio Management License ................................. 8 Primavera P6 Progress Reporter ..................................................................... 10 Primavera P6 Enterprise Project Portfolio Management Web Services License .............. 11 Third Party Notices and/or Licenses .............................................................. 11 AndroidSwipeLayout ................................................................................... 11 aopalliance ............................................................................................. 12 Apache Chemistry OpenCMIS ......................................................................... 12 Apache Commons Net ................................................................................
    [Show full text]
  • ASF FY2021 Annual Report
    0 Contents The ASF at-a-Glance 4 President’s Report 6 Treasurer’s Report 8 FY2021 Financial Statement 12 Fundraising 14 Legal Affairs 19 Infrastructure 21 Security 22 Data Privacy 25 Marketing & Publicity 26 Brand Management 40 Conferences 43 Community Development 44 Diversity & Inclusion 46 Projects and Code 48 Contributions 65 ASF Members 72 Emeritus Members 77 Memorial 78 Contact 79 FY2021 Annual Report Page 1 The ASF at-a-Glance "The Switzerland of Open Source..." — Matt Asay, InfoWorld The World’s Largest Open Source Foundation The Apache Software Foundation (ASF) incorporated in 1999 with the mission of providing software for the common good. Today the ASF is the world’s largest Open Source foundation, stewarding 227M+ lines of code and providing $22B+ worth of software to the public at 100% no cost. ASF projects are integral to nearly every aspect of modern computing, benefitting billions worldwide. Change Agents The ASF was founded by developers of the Apache HTTP Server to protect the core interests of those contributing to and using our open source projects. The ASF’s all-volunteer community now includes over 8,200 committers, involved in over 350 projects that have been organized by about 200 independent project management committees, and is overseen by 850+ ASF members. The Foundation is a globally-distributed, virtual organization with contributors on every continent. Apache projects power countless mission-critical solutions worldwide, and have spearheaded industry breakthroughs in dozens of categories, from Big Data to Web Frameworks. More than three dozen future projects and their communities are currently being mentored in the Apache Incubator.
    [Show full text]
  • Java Naplózás Megvalósítása Jakarta Log4j-Vel Viczián István ([email protected])
    Java naplózás megvalósítása Jakarta Log4J-vel Viczián István ([email protected]) E cikk olyan Java programozóknak nyújt segítséget, kik tisztában vannak a Java nyelv alapjaival, és egy megbízható, elterjedt, jól dokumentált és támogatott naplózó rendszerre van szükségük. A Log4J projekt mindezen jellemzőkkel rendelkezik, és szoros kapcsolatban áll a Jakarta projekt többi tagjával, de persze önállóan is használható. A naplózásra szinte minden szoftver fejlesztésekor szükség van, a legkisebbtől kezdve a komplex, nagyvállalati környezetben használatos, elosztott alkalmazásokig. Nem csupán hibakeresési lehetőség, hanem használható monitorozásra, teljes naplózásra, különböző tesztek sikerességének ellenőrzésére. A naplózás és debug nem keverendő össze, inkább kiegészítik egymást. Van olyan eset, mikor a debugger-ek nem alkalmazhatók, vagy használatuk körülményes lenne, ilyenkor jól jön a naplózás. A naplózás jóval több, mint System.out.println utasítások, elvárásunk lehet, hogy az eseményekhez pontos dátum kapcsolódjon, a különböző szoftverkomponensek üzenetei megkülönböztethetőek legyenek egymástól, szűkíteni vagy bővíteni lehessen a naplózást különböző szintek bevezetésével, a formátum és cél tetszőlegesen konfigurálható legyen (pl. fájl, adatbázis, más hálózati erőforrás). A Log4J egy minden igényt kielégítő naplózó rendszer, mely a felsorolt kívánalmaknak maximálisan megfelel, és egyéb hasznos tulajdonságai is vannak. Bevezeti a loggerek fa hierarchiáját (hasonlóan a csomagokhoz), így naplózáskor kiválaszthatunk bármilyen részfát, és külön
    [Show full text]