Deprecate certain extension points to guide developers?

Given the discussion about E4 and the evolution of Eclipse I’m wondering if it would make sense to flag certain Eclipse extension points as deprecated and add a warning to the PDE tooling if someone uses these extension points. This would help developes to do “the right thing”.

This question came to me while watching The Myth of the Genius Programmer. Björn quoted from this presentation in this post Criticism is not evil . In this video it was explained that tools matter in the sense that they guide new developer in a certain direction.

For example I believe that actions could be marked as deprecated. I see still a lot of questions which relates to actions in the newsgroup and I believe that commands are superior to actions. I know that the description indicates that “org.eclipse.ui.menus” can be used but perhaps more guidance would help?

Any opinions on this?

Update I submitted Bug 285034 for the enhancement in PDE / UI for the warning.

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, With more than one million visitors per month his website is one of the central sources for Eclipse and Android programming information.
This entry was posted in Eclipse and tagged , , . Bookmark the permalink.

16 Responses to Deprecate certain extension points to guide developers?

  1. This is a great idea. If this isn’t in Bugzilla already, you should really submit it.

  2. marc esher says:

    I think if you want to lead new plugin developers down the right path, one good place to start is with the “sample” wizards. For example, when you create a new plugin project, and you select the “Plugin with a view” sample, you get pretty much the same class that’s been in Eclipse since at least 3.3. It’s all action based, all the actions are inner classes, nothing helpful is added to plugin.xml, etc.

    A new developer tends to rely heavily on these types of things. So if the sample code spits out this stuff, well, then that must be how it’s done in the real world, right?

    Instead, it’d be nice if the sample view in this case was a demonstration of best practices…. make it all command based. Make the actions external and show how to properly use MVC in eclipse applications.

    Currently, though, a developer must figure all this out the hard way. This is not to say struggle isn’t important.. it is. But it is to say that there are much more efficient ways to help new developers up this learning curve, and starting with the sample code that’s generated is a good first step.

  3. Lars Vogel says:

    @marc: I completely agree. Please vote for bug there I also send in a patch

  4. Totally agree with the examples ( voted for the bug) and for the deprecated extension point all the more that PDE provides a way to do that now as shown by Benjamin Cabé here :

    And set them deprecated for 3.6 but for e4, is that possible to completely remove them? Or perhaps just set a filter on deprecated extension point when we choose one (as a checkbow like the existing “Show only extension points from the required plugin”).
    I prefer the second which don’t break API.

  5. Eric Rizzo says:

    A most excellent idea. But does the platform have the notion of deprecated extension points already? I don’t think so but I’d be happy to be shown to be wrong.

  6. Lars Vogel says:

    @Eric Yes, the platform has this already. I didn’t know about it either but Benjamin Cabé was nice enough to correct me via Twitter and I was able to fix the blog post just in time. See

  7. Tonny Madsen says:

    I agree completely.

    Like so many others that makes living doing consultancy and mentoring in Eclipse, I think this really could help new developers. When it comes to extension points in Eclipse, *the* questions are which extension points to use for what and where to find the overview of the relevant extension points

    Extension points in Eclipse, comes in three groups:

    - those that are used in the daily work and everybody should know about – like org.eclipse.ui.menus and friends

    - those you might use one per project and only just in a life time – like the many extension points

    - those that should never be used and really should be deprecated – like org.eclipse.ui.popupActions and friends

    The first group – which is the the relevant group for newcomers – is less than 1/3 of all the available extension points….

  8. Eric Jain says:

    If actions are going to be deprecated, shouldn’t Eclipse first allow me to build an application without having to use actions? For example, the following code still appears to be required to enable the save command in an RCP application (via an ActionBarAdvisor subclass):

    protected void makeActions(IWorkbenchWindow window) {


  9. Lars Vogel says:

    @Eric Jan: Can you open a bug for this? I have a similar bug report for resetPerspective

  10. Eric Jain says:

    @Lars: This is perhaps a more general issue as there are quite a few commands that require registering an ActionFactory.*. Added a comment to the existing issue for now…

  11. Daniel Milosevic says:


    I’m one of those new developers to Eclipse RCP and I’ve spent the last couple of weeks working with actions, as Marc mentioned, I saw this in the example and assumed it was the best approach.

    Time to google “Eclipse RCP Commands”!

  12. boyang says:

    i want to develop a plugin for carbide.c++,just convert the cpp to i use eclipse, but i do not know how to debug, i have changed the target platform to carbide.c++ and debug configuration run a pruduct as “”. the error information as follows:
    1.Bundle org.eclipse.equinox.simpleconfigurator_1.0.100.v20090520-1905 [444] is not active.
    2.Product could not be found.
    can you give me some help,thanks!

  13. Nat says:

    Even more important is to have documentation including tutorials:) reflect using newest api’s/technologies ONLY. For example, you might have a tutorial on (JFace) Master/Detail tables with databinding using Eclipse 3.5. All aspects of the tutorial should utilize the latest 3.5 “way of doing it” at any point where 3.5 introduced a newer methodology/api. Then you have the same tutorial for 3.4, pointing out where 3.5 introduced something new, AND advising if the specific 3.4 api can/should/should not/ be used in 3.5.
    Of course it’s tough now to write new docs & tutorials this way for a few revisions, but all we need is a start, say 3.5, then doing it in 3.6, and so on will be simpler.
    Conflicting api’s within Eclipse/JFace is a partial problem. The real problem is lack of CLEAR documentation as I suggested above.
    Thanks for your good effort with the tutorials.

  14. admin says:

    @nat I agree partially. Tutorial are important thats why I try to keep tutorials up to date. But in my opinion it is more important that the templates and default settings are up-to-date because that is there everyone has to start.

Comments are closed.