Eclipse Web Tools Platform Project Charter - v1.7 | |
Overview The Eclipse Web Tools Platform Top-Level Project is an open source collaborative software development project dedicated to providing a generic, extensible, standards-based tool platform for producing Web-centric technologies. This document describes the composition and organization of the project, roles and responsibilities of the participants, and development process for the project. Mission Scope The project will be further limited to providing infrastructure for tooling proper, in contrast to infrastructure related to the application run-time. We will typically use a simple litmus test to set the boundary between tooling and run-time. Application artifacts, once developed, have no execution dependencies on the relevant tooling framework, while the converse would be true for run-time frameworks. In keeping with our objective of maximizing vendor-neutrality, where multiple frameworks exist in the market for a given functional domain, we will develop tooling based on a common abstraction (or superset) to the extent feasible. The ultimate objective of the project is to provide highly reusable and extensible tooling that allows developers to produce applications with increasing development efficiency. The tooling foundation the project will deliver will support these values by enforcing appropriate separations of concern in application architecture, raising the level of technical abstraction in application development and enabling repeatability in development processes. These values, however, will be achieved incrementally over time. Early deliverables will focus on an extensible foundation supporting the most widely used Web and Java standards and technologies. In addition, we expect the Web Tools Platform Project to produce functional requirements that are more appropriately satisfied through the Eclipse Project or other Eclipse foundational projects. Areas in which we might expect to see these elaborated requirements would be in working with components, or supporting complex project layouts. In such case, the Web Tools Platform Project PMC will coordinate the corresponding Project PMCs the design and implementation of the corresponding contribution. The project initially has two projects: Web Standard Tools and J2EE Standard Tools. These two projects will focus on infrastructure for tools used to build applications for standards-based Web and Java runtime environments. Outside the scope of the project is support for vendor-specific application architectures, such as ASP.Net and ColdFusion, or for extensions not backed by the JCP, such as Apache Struts. Expanding the project to include new projects covering these or other areas will require a revision to this charter as per the Eclipse Development Process. Web Standard Tools The Web Standard Tools Project includes server tools which extend the Eclipse platform with servers as first-class execution environments. Server tools provide an extension point for generic servers to be added to the workspace, and to be configured and controlled. For example, generic servers may be assigned port numbers, and may be started and stopped. The Web Standard Tools Project will define an extension for Web servers, which builds on the generic server extension point, and will include exemplary adapters for popular commercial and Open Source Web servers, e.g. the Apache Web Server. Server vendors are encouraged to develop adapters for their Web servers. The Web Standard Tool Project will also include a TCP/IP Monitor server for debugging HTTP traffic, especially SOAP messages generated by Web Services. The generic server extension point is intended to be used for other types of server, for example J2EE application servers and databases, but these are outside the scope of the Web Standard Tools project. J2EE Standard Tools The J2EE Standard Tools Project will build on the Server Tools provided by the Web Standard Tools Project to provide support for application servers, including both servlet engines and EJB containers. The scope of the J2EE Standard Tools Project includes exemplary adapters for popular commercial and open source J2EE servers, e.g. Apache Tomcat, Apache Geronimo, and ObjectWeb Jonas. Server vendors are encouraged to develop adapters for their products. Support of frameworks not covered by the J2EE specification (e.g., Struts, Hibernate, XMLC, JDO) are outside the scope of this project, although such projects could find a home in an Eclipse Technology project. Although the scope of the Web and J2EE Standard Tools projects includes the development of exemplary adapters for popular commercial and Open Source servers, these are not necessarily intended to be the definitive adapters. Instead, they are intended to serve two purposes. First, they are intended to enable users to immediately use these servers, although possibly with not exploiting all their features. Second, they are intended to serve as examples to both commercial and Open Source developers who want to integrate servers into Eclipse. It is consistent with the goals of this project that the exemplary adapters become superseded by more complete implementations provided by third parties, both commercial and open source. Project Management |
![]() |
Project Management Committee The Projects under this Charter are managed by a group known as the Project Management Committee (the “PMC”). PMCs are expected to ensure that:
The PMC has the following responsibilities:
The PMC Lead is appointed by the Board. The initial PMC is selected by the PMC Lead. Thereafter, to become a member of the PMC, an individual must be nominated by another member of the PMC, and unanimously approved by all PMC members. In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by unanimous vote of remaining PMC members. PMC members may resign at any time by delivering notice of their resignation to the PMC Lead. The PMC is responsible for producing and maintaining the Project Charter. Development must conform to any rules or processes outlined in the Charter, so a change to the development process may necessitate a change to the Charter. Changes to the Charter are approved by the Board. The work of the PMC is shared by the PMC members. All PMC members are expected to contribute actively. In particular, PMC members are expected to take responsibility for overseeing certain areas of work in the Project, and reporting to the PMC on these areas. Active participation in the user newsgroups and the appropriate developer mailing lists is a responsibility of all PMC members, and is critical to the success of the Project. PMC members are required to monitor the main Project mailing list, and the developer mailing lists for all Projects and components they are overseeing. |
![]() |
Project Requirements Group The Requirements Group is formed at the discretion of the PMC. The Requirements Group gathers requirements for the project and communicates them to all members of the Project, including the PMC. The Requirements Group will accomplish its objectives by working closely with the development teams and the PMC. |
![]() |
Project Architecture Group The Architecture Group is formed at the discretion of the PMC. The Architecture Group is responsible for development, articulation and maintenance of the Project Architecture, as well as for providing an explicit description of the architecture and communicating this description to all members of the Project, and for releasing it as part of the project deliverables. The Architecture Group will accomplish its objectives by working closely with the development teams and the PMC. |
![]() |
Project Planning Group The Planning Group is formed at the discretion of the PMC. The Planning Group assists the PMC in establishing the Project plan in conjunction with available Project resources, coordinating relationships between Project participants and with other Eclipse projects. The Planning Group helps to ensure that projects have enough contributors, filling vacancies in roles and facilitating code or other donations by individuals or companies. The Planning Group will accomplish its objectives by working closely with the development teams and the PMC. |
Roles Users Developers Committers In order for a Developer to become a Committer on a particular Project overseen by the PMC, another Committer for the same Project (or component as appropriate) can nominate that Developer or the Developer can ask to be nominated. Once a Developer is nominated, the Committers for the Project (or component) will vote. If there are at least 3 positive votes and no negative votes, the Developer is recommended to the PMC for commit privileges. If the PMC also approves and the Developer signs the Committer Agreement established by the EMO (wherein, at the very least, the Developer agrees to abide by the Eclipse Intellectual Property Policy), the Developer is converted into a Committer and given write access to the source code repository for that Project (or component). Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly. At times, Committers may go inactive for a variety of reasons. The decision making process of the Project relies on active committers who respond to discussions and votes in a constructive and timely manner. The PMC is responsible for ensuring the smooth operation of the Project. A Committer that is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status removed by the PMC. Active participation in the user newsgroup and the appropriate developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user newsgroup. Committers are required to monitor the developer mailing list associated with all Projects and components for which they have commit privileges. This is a condition of being granted commit rights to the Project or component. It is mandatory because committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a developer mailing list unless their associated commit privileges are also removed. Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects and components. There are three voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain). Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from the submitter. Committers are responsible for updating problem reports when they have done work related to the problem. Development Process When a new Project is created, the PMC nominates a Project lead to act as the technical leader and nominates the initial set of Committers for the Project, and these nominations are approved by the EMO. Project leads are accountable to the PMC for the success of their Project. Project Components Coordinated Release Cycles Infrastructure
The Development Process Each Project must identify, and make available on its web site, the requirements and prioritizations it is working against in the current release cycle. In addition, each Project must post a release plan showing the date and content of the next major release, including any major milestones, and must keep this plan up to date. The Committers of a Project or component decide which changes may be committed to the master code base of a Project or component respectively. Three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a code change. Vetoes must be followed by an explanation for the veto within 24 hours or the veto becomes invalid. All votes are conducted via the developer mailing list associated with the Project or component. Special rules may be established by the PMC for Projects or components with fewer than three Committers. For efficiency, some code changes from some contributors (e.g. feature additions, bug fixes) may be approved in advance, or approved in principle based on an outline of the work, in which case they may be committed first and changed as needed, with conflicts resolved by majority vote of the Committers of the Project or component, as applicable. More restrictive rules for releasing changes may be established by the PMC near the end of release cycles or for maintenance streams. The master copy of the code base must reside on the Project web site where it is accessible to all users, developers and committers. Committers must check their changes and new work into the master code base as promptly as possible (subject to any check-in voting rules that may be in effect) in order to foster collaboration among widely distributed groups and so that the latest work is always available to everyone. The PMC is responsible for working with the Eclipse Foundation to establish a release engineering and build process to ensure that builds can be reliably produced on a regular and frequent basis from the master code base and made available for download from the Project web site. The PMC is responsible for establishing the level of testing appropriate for each Project, and approving the test plans. All development technical discussions are conducted using the development mailing lists. If discussions are held offline, then a summary must be posted to the mailing list to keep the other committers informed. Licensing |