Ian is an Eclipse committer and EclipseSource Distinguished Engineer with a passion for developer productivity.
He leads the J2V8 project and has served on several …
Eclipse is an extensible IDE, giving users lots of freedom (and opportunity) to customize the tool for their own use. However, sometimes you run up against a barrier and the only way to get around it is to download and modify the source code yourself.
For example, let’s say you love the Eclipse Package Explorer, but you really wished it was an ‘Awesome Explorer’. While there might be some extension points your could use to customize the view, sometimes API’s are simply not exposed.
Once you’ve fetched the source code and made the appropriate changes, how do you tell Eclipse to use your version instead? Many Eclipse plugins and features define ‘strict inclusions’ meaning that they expect a certain version of the plugin to be installed. This is often done for reproducibility – so users can rebuild an exact tool-chain configuration at some future date. Some may argue that a newer version should always trump an older version, but that logic quickly breaks down when you realize that newer is not always better. Certainly newer plugins can’t always be used as a drop-in-replacement for an older one.
You can certainly re-build the entire Eclipse stack, replacing the ‘strict inclusions’ with your own version of the plugin. However, this is often a lot of work and you may not even have access to all plugins which define these rules.
Luckily the Eclipse provisioning platform (p2) has a solution – feature patches. A feature patch is a binary replacement for an existing version of a feature, with some of the included plugins replaced with different versions. In our case, we would provide a feature patch for the JDT with a replacement for the org.eclipse.jdt.ui plugin.
The New Feature Patch dialog creates a feature patch (com.example.awesome.explorer) that can be used to patch a specific version of the org.eclipse.jdt feature. Make sure you include your modified org.eclipse.jdt.ui plugin:
You can now export your feature patch to a p2 repository (feel free to categorize it so users can find the component more easily):
And finally, install the feature patch into your IDE:
And now you’ll have the most excellent ‘awesome explorer’ :-)
If creating and managing Feature patches (and p2 repositories) is more work than you’d like to do, you can simply export the modified plugin into your existing install. This action will create the feature patch (and p2 repository) behind the scene and install the modified component for you:
Keep in mind that a feature can only be patched once. If you’ve already patched the JDT (or are using an Eclipse install with a patched version of the JDT), you’ll have to un-install that feature patch before installing your own.
For more Eclipse Tips and Tricks (and the annual Top 10 List), why not follow me on twitter:
Ian is an Eclipse committer and EclipseSource Distinguished Engineer with a passion for developer productivity.
He leads the J2V8 project and has served on several …