|Mailing List • Forums • IRC • mattermost|
|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 email@example.com to your watch list.
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 committed to CVS. To do so you must create a patch and attach it to the bug report. 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.
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 CVS. 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 CVS repository: Go to the CVS Repository Exploring Perspective. In the CVS Repositories view you can add the repo by pasting the following (or creating a new connection and filling in the fields in the wizard).
- 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.