plugin_customization.ini and Eclipse preferences

After reading the post from Mich I figured I would add another little hidden gem to the discussion.  While this is not a comprehensive list of what settings can go in that file, it should explain why that list is so elusive.

plugin_customization.ini is actually a file that can be used to set any Eclipse preference on startup.  Given that, the settings that can go in there are basically whatever preferences any plugin sets.  So, do you want to know where those settings are persisted in the client?  In the Notes data directory follow this path:

workspace.metadata.pluginsorg.eclipse.core.runtime.settings

That directory contains all of the “.prefs” files for each and every plugin – ie. each one of those files is a preference store.  They are readable to the human eye in a text editor so crack one open in your favorite text editor.

Here is how it works;  we will use the preference setting Mich mentions in his post:

com.ibm.notes.branding/enable.update.ui=true

The format of the entry is this:     <plugin id> / <setting> = <value>

So if you look for the file “com.ibm.notes.branding.prefs” and open it you will see all of the Eclipse preferences this plugin supports.  Usually these can be controlled by the Application | Preferences panels but some are only set in code.  Just depends if you want users changing them or not.  Here are the contents of that file (com.ibm.notes.branding.prefs):

#Fri Aug 27 15:16:57 EDT 2010
enable.update.ui=true
eclipse.preferences.version=1

One more thing to keep in mind.  Policies can also enforce preferences.  So if you change this file and put a preference that is controlled by Domino Policy it will be changed immediately when you launch the client.

12 thoughts on “plugin_customization.ini and Eclipse preferences

    • Managed settings is actually a very complicated federated system where there can be many “providers”. The Domino provider is done through Domino Policies (which is stored in the NAB) and you can also control basic Eclipse preferences from policies. So in short, if a managed setting is mapped to a plugin preference then its ultimately stored as a preference.

      Like

  1. Bob

    Thanks for adding a piece to the puzzle, while I understand that plugin_customization.ini is an Eclipse file, and therefore the possibilities are endless, I am asking for the Lotus Product specific documentation, not all of Eclipse

    Like

  2. Thanks for the extra info Bob. I had actually just sorted out where some preferences were the hard way so this is timely. In my case I was looking for bits related to the Feeds sidebar, so that I could programmatically make the “subscribe to preset feeds” button reappear if it wasn’t visible. I had also written a button to overwrite the presetfeeds.opml file so that the subscribe button had something interesting to import.

    All fine and good, but is there a way to avoid having to restart the Notes client to get things like the subscribe button to show after editing the setting in the backend? Using the normal preferences panel to make it reappear takes effect immediately. Requiring a restart really hampers my ability to automate this process. Of course, it would be even better if I could figure out how to actually *trigger* the subscribe button via a script of some sort.

    The overall goal here is to be able to display a page of buttons that add functionality or otherwise do cool stuff to and with the sidebar. Could be a button in an email, could be a central xpages based page, who knows. If you have any other ideas to pull this off I’d love to hear ’em.

    Thanks!

    Like

  3. Bob,

    Why is it that if a Domino Policy pushes out a eclipse setting, that it does not show up in the users plugin_customization.ini on the notes client? (ex. like the notes.ini does?) As you have mentioned, it only reflects the changes in the preference store file(s). I always assumed when using a policy to deploy these settingspreferences it would always show up in the users plugin_customization.ini, but it does not.

    TIA,
    Tim E. Brown

    Like

  4. The plugin_customization.ini is a static file only used on startup. It is a way for the install or a user to specify a preference to Eclipse so its used on startup. It is not anything like the notes.ini actually, it is very different. The individual .prefs files are more like the Notes.ini in this case.

    Like

  5. Bob,

    I’m trying to deploy my features/plugins with the Notes Addon Installer Toolkit to the IBM Notes client. So far, so good (setup is ready, features/plugins are signed, …).
    Now I’m searching for a way to deliver individual plugin-preferences (I don’t want to use a desktop policy). I tried it with the plugin_customization.ini within the installer toolkit. But these settings don’t have any effect.

    Do you have any idea?

    Thanks,
    Alex

    Like

    • Unfortunately you will have to use desktop policies unless something changed since I left. You could also deploy a plugin that sets the preferences manually in code but then everyone would get the same values.

      Bob

      Like

  6. Pingback: Thank you for a great 2015 and Happy New Year! | Bob's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s