|Mailing List • Forums • IRC|
|Browse Source • Project Set File|
The PDE project is structured into four major components: api tools, build, ui and incubator.
API tooling will assist developers in API maintenance by reporting API defects such as binary incompatibilities, incorrect plug-in version numbers, missing or incorrect @since tags, and usage of non-API code between plug-ins. The tooling will be integrated in the Eclipse SDK and will be used in the automated build process. Specifically, the tooling is designed to do the following:
- Identify binary compatibility issues between two versions of a software component or product.
- Update version numbers for plug-ins (bundles) based on the Eclipse versioning scheme.
- Update @since tags for newly added classes, interfaces, methods, etc.
- Provide new javadoc tags and code assist to annotate types with special restrictions.
- Leverage existing information (in MANIFEST.MF) to define the visibility of packages between bundles.
- Identify usage of non-API code between plug-ins.
- Identity leakage of non-API types into API.
Ant based tools and scripts to automate build processes
Models, builders, editors and more to faciliate bundle development
Incubator components vary in maturity level and are supported by the respective component leads.
The PDE project places a very high value on community contributions.
This document is intended to help those interested contribute to PDE. It communicates our conventions and discusses ways to get your contributions prioritized. There are many ways that you as a member of the community can get involved and contribute to the PDE Project.
The first step is to let us know you are out there, check out the different ways we communicate and chat with us about your problems and interests.
You should also sign up for a Bugzilla account and add firstname.lastname@example.org to your watch list.
Creating Bug Reports
If you encounter a bug while working with Eclipse (whether it be with PDE or elsewhere), file a report in bugzilla. However, keep some things in mind:
- Search bugzilla for existing bugs like yours BEFORE you file it. Resolving duplicates is time consuming.
- Try to have reproducible steps. An entry in the log file may not be enough. Some log entries are NOT bugs, and can be caused by incorrect workspace configuration, etc.
- Bugzilla is not a forum. Do not ask questions on bugzilla.
- New feature requests should be marked with a severity of enhancement. Try to give a realistic severity to bugs, a bug with a straightforward workaround is not critical or blocker
- Bugs have a lifecycle you should be aware of:
- NEW - All newly filed bugs start out in the NEW state.
- DUPLICATE/INVALID/WORKSFORME/WONTFIX - If a bug is a duplicate of another bug or if a committer decides that no code changes will be made for the bug, the bug is resolved immediately with an explanation. Unless the bug is REOPENED for some reason, this is the end of the road.
- ASSIGNED - If an individual wants to take ownership of a bug (committer or contributor willing to work on it), the bug is reassigned to them, removing it from the inbox. If there is an expected timeframe for the bug to be fixed in, set the target milestone.
- RESOLVED-FIXED - Bugs are marked as RESOLVED-FIXED once code that solves the issue has been pushed to Git. If a patch was provided by a non-committer it must be marked with the IP Log flag by the committer that pushed the code to Git. Proving a brief explanation of the fix/a list of affected files is recommended.
- VERIFIED - PDE does not explicitly verify bugs. However, if the original reporter or a second committer confirms that a fix does in fact fix the original problem, the bug may be marked as verified.
In general we follow the standard Eclipse coding style, some things such as indentation, brackets, imports, etc. are enforced by pde project preferences, so your file will be updated when you save. Try to make your code easily readable adding comments where necessary. Add javadoc (Alt-Shift-J) to public methods and classes, even if they are not API. Once you have created a fix and tested it, you will need it pushed to Git. To do so you must either create a patch and attach it to the bug report, or create a Git commit and push it to Gerrit. A committer will review and commit the fix.
To create a patch, select all of the changed projects in the Package Explorer view. Right click and go to Team > Synchronize, this should open up the Synchronize View. In the Synchronize View, make sure there are no conflicting changes and that all of your changes follow the coding guidelines. Then select your outgoing changes, right click and go to Create Patch... In the dialog, select a destination for the patch (it is best to include the bug number in the file name and use the extension .patch), double check all your changes are included, then hit OK. Attach the created patch to the bug report.
To create a commit and push it to Gerrit, use EGit or the Git command line to clone a PDE repository, create a new branch, make your changes and commit them to your local repository. A PDE commit message should look like this:
Bug 123456: A one-line description of the change A relatively brief description of the commit. For longer discussions, use the bug report. Bug: 123456 Change-Id: I0123456789abcdef0123456789abcdef01234567 Signed-off-by: Committer Name <email@example.com>
Note that EGit can automatically append Change-Id and Signed-off-by. If others have assisted with a commit, use Also-by. For more information on all the checks and balances, see .
Configure Gerrit to point to the Eclipse Gerrit system, and use 'Push to Gerrit...' to make the push. The review URL will be returned as part of the response.
We must follow the Eclipse IP Process. Small contributions will be reviewed and marked with the IP Log flag. Larger contributions will require additional steps.
- There is one mailing list that is used for developer discussions.
- We are active on IRC channels #eclipse and #eclipse-dev
- PDE has a newsgroup where users can ask for help
- Eclipse Code Conventions
- Eclipse User Interface Guidelines
- Documentation Style Guidelines
- Eating your own dog food (Wikipedia)
The recommended way to work with PDE is by checking them out of Git. Doing this makes it easy to try the latest changes and work with patches and ensures that you can easily browse the source code and documentation.
We eat our own dogfood so we try to use a recent Eclipse build so that we are testing as we work. Updating to the most recent i-build each week is preferred. You can use update sites to update your current build or download a recent build.
Consider installing and using Mylyn. It can make it easier to switch between tasks. It connects well with Eclipse, PDE and bugzilla.
Eclipse code is written, edited and tested within Eclipse. This is called self-hosting. Here are the basic steps to self host:
- Setup the Git repositories: Go to the Git Repository Exploring Perspective. In the Git Repositories view, add a repository by pasting one of the following repository URIs (or clicking 'Clone a Git repository and add it to this view'):
git://git.eclipse.org/gitroot/pde/eclipse.pde.git git://git.eclipse.org/gitroot/pde/eclipse.pde.ui.git git://git.eclipse.org/gitroot/pde/eclipse.pde.build.git
Alternatively, you can use the Github mirrors:
https://github.com/eclipse/eclipse.pde.git https://github.com/eclipse/eclipse.pde.ui.git https://github.com/eclipse/eclipse.pde.build.git
- Select the master branch from the repository, or another if required. This branch follows the latest development on as-yet-unreleased PDE.
- Look in HEAD for the 'pde' folder. Inside that folder is a project called 'org.eclipse.pde.releng'. Right click and go to Check Out to copy the project to your workspace.
- Switch back to the Java perspective, inside the releng project there are a number of .psf files. These project set files can be used to quickly check out the projects you are interested in working on. The pde-ui-basic.psf is where most contributors should start. Simply right click on the file and go to import team project set. A dialog may pop up requiring you to choose a repository to use, as committers must use different settings then contributors.
- You can now edit the code in your workspace. To test your code you must create an Eclipse Launch Configuration. The easiest way to do so is to right click on your project, go to Debug As (or Run As) > Run-time Workbench. Your initial Eclipse instance that you edited your code in is called the host. The Eclipse you just launched is called the target. Any changes you make in your host will be reflected in the target.