Home > work > Internal Extension Points

Internal Extension Points

March 28th, 2008

What do people think about internal extension points? Currently, there is no concept about “internal” extension points in Eclipse besides using the convention of having “internal” (ie., internalTweaklets) in the extension point name along with some terse documentation. I know there are also products that don’t ship extension point schemas (.exsd) to prevent their users from extending schemas they don’t want. This is kind of funny because Eclipse is still aware of the extension point it just can’t help the user extend it… since there’s no schema… in essence… the extension point is being hidden… yet it is still there:

I think we can do better than this and try to mimick the concept we have with internal packages and x-friends. For example, imagine an extension point you wanted to define to be used just but your plug-ins for now… it’s useful for you internally but not ready to open to the public yet. In PDE, we could allow you to define an extension point as internal and maybe give it some “friends” that wouldn’t be flagged as discouraged access to the extension point.

What does the community think? Is this something valuable for people?

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • DZone
  • LinkedIn
  • Technorati
Author: Chris Aniszczyk Categories: work Tags: , ,
  • Chris Aniszczyk (zx)
    Sure, but an informal description isn't the same as having tooling to help you understand you're using something internal. Imagine Eclipse without discouraged access warnings for packages, but expecting you to read the "documentation"
  • Sven Efftinge
    I don't think that everything becomes public API just because it is technically available. API also consists of informal description on how to use it. So for me it would be enough to state it in the documentation that an extension point shouldn't be used.
  • Laurent Goubet
    Well This would interest me for sure ;) (I'm the one who asked this on #eclipse just yesterday :D).


    As kevin implied, extension points we define are for now directly becoming API and must be maintained even when they are WIP or simply not aimed at being made publicly available.



    Definetly +1 on this matter.
  • Kevin McGuire
    Makes sense, extension points are just the mechanism for cross plugin call dependency management. There's nothing inherent in them that implies that those are contracts for public consumption. They're orthogonal though obviously related concepts.


    Not sure in practice how often it'd be needed but for those 1/100 cases it prevents accidental leaking or implying of API so valuable.
  • Chris Aniszczyk (zx)
    Unfortunately EMF isn't in the SDK so we can't do that.


    Maybe in the Eclipse 4.0 timeframe we can revisit PDE and EMF integration.
  • David Carver
    PDE using the EMF XSD library to read and write the schemas, and then using the data model provided for editing would be even better. This way it opens up extension points to other patterns.
blog comments powered by Disqus
Get Adobe Flash playerPlugin by wpburn.com wordpress themes