Twitter github

platform.xml and MANAGED_ONLY

Sometimes I get really strange emails from random people asking for Eclipse help. I guess this goes with the domain of being in the open-source world. I can’t always answer all the emails as that’s not really my day-time job, but my rule of thumb is if I can come up with an answer under a minute, I’ll try to respond. Today I actually got an interesting question…

…how do I prevent people from just “dropping bundles” into an Eclipse product installation and having them appear in my product…

In Eclipse, we have something called the update configurator which scans for new bundles and does the magic of installing them when Eclipse boots. It does this because of something called an “update policy.” By default, Eclipse comes with the USER_EXCLUDE policy which simply will install everything located in that location (see the snippet below). There’s another update policy called MANAGED_ONLY which runs Eclipse with the plug-ins specified via the platform.xml… this will effectively “lockdown” your Eclipse application to only what is specified in the platform.xml file (security through obscurity, right ;p?).


<?xml version="1.0" encoding="UTF-8"?>
<config date="1185215657453" transient="false" version="3.0">
<site enabled="true" policy="MANAGED_ONLY" updateable="true" url="platform:/base/">
<feature id="org.eclipse.rcp.source" url="features/org.eclipse.rcp.source_3.3.0.v20070607-8y8eE8NEbsN3X_fjWS8HPNG/" version="3.3.0.v20070607-8y8eE8NEbsN3X_fjWS8HPNG">
</feature>
...

  • Jim Adams

    I think you answered the wrong question. I have to ask “Which product are we talking about?” For the IDE product this is exactly the behavior that is desired. Wild west free-for-all. Sometimes that isn’t desirable as this can have unintended consequences on other plugins but still, the product allows for this. If, on the other hand, we are talking about an RCP product, then I have to wonder where they are getting their list of plugins to install from? If they are using the UpdateConfigurator then they have asked for this behavior. If they then don’t want that behavior then they have to find another way of providing the list of plugins to the app.

  • Jim Adams

    I think you answered the wrong question. I have to ask “Which product are we talking about?” For the IDE product this is exactly the behavior that is desired. Wild west free-for-all. Sometimes that isn’t desirable as this can have unintended consequences on other plugins but still, the product allows for this. If, on the other hand, we are talking about an RCP product, then I have to wonder where they are getting their list of plugins to install from? If they are using the UpdateConfigurator then they have asked for this behavior. If they then don’t want that behavior then they have to find another way of providing the list of plugins to the app.

  • Chris Aniszczyk (zx)

    “For the IDE product this is exactly the behavior that is desired. Wild west free-for-all.”

    I disagree. If you’re a proprietary product, IDE or not, you may want to be VERY careful which plug-ins may be included. For RCP applications, this may make sense, but working with clients, there have been cases where clients only want their approved plug-ins be used via their update site.

  • Chris Aniszczyk (zx)

    “For the IDE product this is exactly the behavior that is desired. Wild west free-for-all.”I disagree. If you’re a proprietary product, IDE or not, you may want to be VERY careful which plug-ins may be included. For RCP applications, this may make sense, but working with clients, there have been cases where clients only want their approved plug-ins be used via their update site.