blob: dcae9730a3d02d0dc3e1c79357fd534b4c55bfc9 [file] [log] [blame]
This document is provided as a template along with some guidance for creating
your project proposal. This is just a template. Feel free to change it as
you see fit (add sections, remove section). We feel, however, that the
suggestions represented in this document represent the reasonable minimum
amount of information to move forward.
Please keep the formatting in this document simple. Please do not edit
this document in Microsoft Word as it adds huge piles of markup that make
it difficult to restyle.
More information is available here:
Direct any questions about this template to
Include the title here. We will parse it out of here and include it on the
rendered webpage. Do not duplicate the title within the text of your page.
<title>Common Build Infrastructure</title>
We make use of the 'classic' HTML Definition List (dl) tag to specify
committers. I know... you haven't seen this tag in a long while...
dt {
display: list-item;
dd {
<p>The Common Build Infrastructure (CBI) project is a proposed open source project under the <a
The communication channel must be specified. Typically, this is the
"Proposals" forum. In general, you don't need to change this.
<p>This proposal is in the Project Proposal Phase (as defined in the
Eclipse Development Process) and is written to declare its intent and
scope. We solicit additional participation and input from the Eclipse
community. Please send all feedback to the
<a href="">Eclipse Proposals</a>
Optionally provide the background that has lead you to creating this project.
<p>The Eclipse Foundation hosts a large number of projects. Historically, each project has implemented their
own build system from scratch with mixed results. We believe collaboration around a common set of software
production technologies such as build, testing, and similar can have a positive effect on Eclipse projects.</p>
All projects must have a well-defined scope. Describe, concisely, what
is in-scope and (optionally) what is out-of-scope. An Eclipse project
cannot have an open-ended scope.
<p>The Common Build Infrastructure (CBI) project maintains and develops software
production technology common to multiple Eclipse projects.</p>
<li>Make it really easy to build Eclipse projects</li>
<li>Make it easy to automate build and testing tasks</li>
<li>Make it really easy to sign jar files and other artifacts</li>
<li>Make it easier for new projects to set up their build</li>
<li>Continually improve the quality of builds at Eclipse</li>
<p>It is important to differentiate between common and universal. CBI does not abstract all
build systems or rarely needed features. If something is used by one and only one project, it is
unlikley to be included as part of CBI.</p>
<p>Once multiple projects are using a given technology something, then it may become a candidate for
inclusion into CBI if doing so brings benefit to CBI and projects using it.</p>
<p>The following components are examples of technology that is within the scope of CBI:</p>
<li>Jar signing service</li>
<li>Operating system signing service</li>
<li>Common Maven plugins used for Eclipse builds</li>
<li>Common Eclipse license files</li>
Describe the project here. Be concise, but provide enough information that
somebody who doesn't already know very much about your project idea or domain
has at least a fighting chance of understanding its purpose.
<p>The Eclipse Common Build Infrastructure (CBI) combines technologies and practices
for building Eclipse Software.</p>
<h2>Why Eclipse?</h2>
Answer these two questions: What value does this project bring to the Eclipse
community? What value do you expect to obtain from hosting your project at Eclipse?
What value do you get by having your project at Eclipse over and above the value
of hosting at Eclipse Labs?
<p>Given the Eclipse-focused background and scope, creating CBI as a project itself hosted at
the Eclipse Foundation is very natural. CBI makes setting up and maintaining project builds easier.
Creating the CBI project allows people to contribute to CBI on equal footing and hopefully will
assist in growing a community for CBI over time.</p>
<h2>Initial Contribution</h2>
Projects are expected to arrive at Eclipse with existing code.
Describe the existing code that will be contributed to the project. Please provide
a couple of paragraphs describing the code with modest detail, including important
information like code ownership (who holds the copyright?), and some consideration
of community that exists around the code. Include a listing of third-party libraries
and associated licenses.
<p>CBI code is licensed under a mix of EPL and EDL code. For example:</p>
<li>Data, notably the pom.xml files are EDL</li>
<li>Code is EPL e.g. the jar signer</li>
<p>The headers in each file denote the license.</p>
<p>Copyright for the CBI project's initial contribution is held by the Eclipse Foundation, SAP, IBM, and Red Hat.</p>
<p>The initial contribution is hosted by the Eclipse Foundation already at the following URL:</p>
<li><a href="git://">Git Repository for Maven plugins</a></li>
<li><a href="git://">Git repository for the common license files</a></li>
<li><a href="">Git repository for the signing service</a></li>
<h2>Legal Issues</h2>
Please describe any potential legal issues in this section. Does somebody else
own the trademark to the project name? Is there some issue that prevents you
from licensing the project under the Eclipse Public License? Are parts of the
code available under some other license? Are there any LGPL/GPL bits that you
absolutely require?
<p>We do not believe there are any legal issues lurking in CBI.</p>
List any initial committers that should be provisioned along with the
new project. Include affiliation, but do not include email addresses at
this point.
<p>The following individuals are proposed as initial committers to the project:</p>
<dt>Thanh Ha, Eclipse Foundation</dt>
<dd>Thanh is a committer on the CBI project where he has made significant contributions over
the past year. He will be developing and maintaining: the signing service; the operating system
signing service; and Maven plugins.</dd>
<dt>Paul Webster, IBM</dt>
<dd>Paul Webster is a power user and periodic contributor to CBI. He was a significant contributor to the efforts to deploy CBI for
The Eclipse Platform project.</dd>
<dt>Krzysztof Daniel, Red Hat</dt>
<dd>Krzysztof is a power user and periodic contributor to CBI. He was a significant contributor to the efforts to deploy CBI for
The Eclipse Platform project and the Fedora Linux distrubution's Eclipse build.</dd>
<dt>David Williams, IBM</dt>
<dd>David is a power user and periodic contributor to CBI. He was a significant contributor to the efforts to deploy CBI for
The Eclipse Platform project.</dd>
<dt>Denis Roy, Eclipse Foundation</dt>
<dd>Denis was the original author of the signing service and plans to continue developing it.</dd>
<p>We welcome additional committers and contributions.</p>
Describe any initial contributions of code that will be brought to the
project. If there is no existing code, just remove this section.
New Eclipse projects require a minimum of two mentors from the Architecture
Council. You need to identify two mentors before the project is created. The
proposal can be posted before this section is filled in (it's a little easier
to find a mentor when the proposal itself is public).
<p>The following Architecture Council members will mentor this
<li>Gunnar Wagenknecht</li>
<li>John Arthorne</li>
<h2>Interested Parties</h2>
Provide a list of individuals, organisations, companies, and other Eclipse
projects that are interested in this project. This list will provide some
insight into who your project's community will ultimately include. Where
possible, include affiliations. Do not include email addresses.
<p>The following individuals, organisations, companies and projects have
expressed interest in this project:</p>
<li>Andrew Ross, Eclipse Foundation</li>
<li>Gunnar Wagenknecht, Tasktop</li>
<li>Lars Vogel, vogella GmbH</li>
<li>Alexander Kurtakov, Red Hat</li>
<li>Mickael Istria, JBOSS by Red Hat</li>
<li>Toni Menzel, rebaze GmbH</li>
<li>Wim Jongman, Remain Software</li>
<li>Stephan Leicht Vogt, Business Systems Integration AG</li>
<li>Pat Huff, IBM</li>
<li>Jutta Bindewald, SAP</li>
<li>Jochen Krause, EclipseSource</li>
<li>Paul Lipton, CA Technologies</li>
<h2>Project Scheduling</h2>
Describe, in rough terms, what the basic scheduling of the project will
be. You might, for example, include an indication of when an initial contribution
should be expected, when your first build will be ready, etc. Exact
dates are not required.
<h2>Changes to this Document</h2>
List any changes that have occurred in the document here.
You only need to document changes that have occurred after the document
has been posted live for the community to view and comment.
<td>Document created</td>