Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Development Resources/The First 90 Days

Some of this content is out-of-date. The handbook has more current information.

This document is under development.

Getting started with your new Eclipse project can be a little daunting. There's a lot to learn and a lot of work to do. If you need help, or aren't sure what you need to do, get help. Ask your project mentors, or the EMO for help (start with your mentors). Your mentors are there to help (note that you can identify your project mentors directly from the project proposal; they're also listed on your project's "project information" page which is accessible form the List of Eclipse Projects.

Getting Started

Please see Starting A New Project.


After your project has been created via creation review, the new project lead will be sent a note from the Eclipse Management Organization (EMO) with instructions for provisioning. You will be required to provide information including the type of code repository your project will use (Git is preferred), as well as the identities of the committers on your new project. The EMO staff uses this information to create all the backend resources required by your project.

Committing Code

Before any code is committed into the newly provisioned source code repository, you must take an initial contribution through the Eclipse IP due diligence process. The initial contribution is the code base that you've brought to the project. You must receive explicit approval from the IP team before you commit any code into the project's repository.

Parallel IP

To expedite the IP process, your project can take advantage of the parallel IP process. With the parallel IP process, you'll potentially be able to get your code into the project repository sooner. The idea is that you can get check-in permission while the IP due diligence process runs in parallel. You still need to wait for the IP team to give you a go-ahead before you commit any code into the project's repository.

In order to take advantage of "Parallel IP", a project is required to conform to incubation branding rules. The basic idea is that you need to put certain indicators on your project landing page, downloads page, and downloads to inform the community that the project and its code are not considered mature.

Note that the end result of the IP team's due diligence may require that some or all of the code or library under consideration be removed from your project (approximately 5% of third party libraries are ultimately rejected by the IP team; 25-30% of all reviews require some modification, e.g. removal of files). Be prepared for this. When code or a library is rejected by the IP team, it must be removed from all means of distribution at Eclipse; this includes the project's source code repositories, downloads server, and website. Webmaster can help with the mechanical process of removing the rejected code, but the impact of the removal of that code on the balance of the code will be the project's responsibility to bear.

Tracking Contributions

Many contributions to a project must be checked by the Eclipse Intellectual Property (IP) Team prior to their inclusion by an Eclipse Project or distribution from an property. Contribution questionnaires (CQ) are the main interface between the Eclipse community and the Eclipse IP Team.

Third Party code

You need a contribution questionnaire (CQ) for a third-party library if you make direct use of that library. An import statement in Java source, or a bundle reference or package reference in a manifest file are examples of a direct reference. A separate CQ is required for each dependency of a third-party dependency (i.e. the transitive closure of dependencies for a third-party library must be represented by CQs). Indirect references through another Eclipse project's code do not generally require a CQ.

There is a special allowance when it comes to dependencies that are used exclusively for build and test. Build and Test dependencies (which are used exclusively by your project's test code, and are not directly distributed from can be lumped together into a single CQ. These dependencies do not go into the SCM and are not distributed from

Images, Icons, and other Non-Code Artifacts

Images, icons, property files, configuration files, documents and other artifacts are intellectual property and are subject to the IP process. Don't forget these when you're assembling your initial contribution.

Project Website

A solid web presence is important for every Eclipse project. The website is very often the first point of contact with the community and your project's best hope of attracting users, adopters, and contributors.

Creating a website is something that you can do while you are waiting for the IP team to complete their due diligence on your initial contribution.

The project website will be provisioned with a template site. At this point in the project's lifecycle, probably the easiest thing to do is to point the project's website (at least temporarily) to the new data-driven website. The data-driven website will, for example, automagically provide the incubation branding required to qualify for parallel IP.


Your project can provide milestone builds for an upcoming release on your project's download site. To do an official release, however, you must engage in a release review. Note that milestone builds are generally intended for a restricted audience.

Milestone builds may only intellectual property (including third-party code) for which check-in approval has been granted (note the CQs do not need to be fully approved).

Builds of all kinds (including milestone builds) should be stored in the project's directory on the download server. Milestone builds should be labelled as such (e.g. 0.7.0M1) and--while your project is in the incubation phase--conform to the [branding requirements].


Building a community is an important part of life as an Eclipse project. It is critical that you are as responsive as possible to the community during these first days of life as a project at Eclipse. Ensure that your project team is monitoring the project forums and newsgroup. Teach your project members to be polite and courteous when dealing with the community.

Get into the habit of opening bugs. Document team discussions on the project website, wiki, or mailing list. Blog, tweet, podcast. Make it easy for people to find your project, learn about what you're doing, and get involved.


This document is moderated by the EMO.

Back to the top