Comments on: OSGi, Dynamics and Eclipse http://eclipsesource.com/blogs/2009/07/23/osgi-dynamics-and-eclipse/ Eclipse Equinox OSGi Wed, 16 May 2012 08:22:45 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Ralf Ebert http://eclipsesource.com/blogs/2009/07/23/osgi-dynamics-and-eclipse/comment-page-1/#comment-3245 Ralf Ebert Thu, 17 Dec 2009 14:15:36 +0000 http://eclipsesource.com/blogs/?p=2148#comment-3245 Chris, are you aware of any plans to add such a "Dynamic-Aware" manifest header? Seems like a reasonable addition and would certainly reward people that are sticking to the rules regarding OSGi's dynamic nature. Chris, are you aware of any plans to add such a “Dynamic-Aware” manifest header? Seems like a reasonable addition and would certainly reward people that are sticking to the rules regarding OSGi’s dynamic nature.

]]> By: Philipp Kursawe http://eclipsesource.com/blogs/2009/07/23/osgi-dynamics-and-eclipse/comment-page-1/#comment-2391 Philipp Kursawe Fri, 24 Jul 2009 05:51:21 +0000 http://eclipsesource.com/blogs/?p=2148#comment-2391 That StringVariablePresentationManager screams for a refactoring patch then. Regarding extension I wonder what the best approach should be: Save the extensions in an internal state (a map like in your second example). Or query the available extensions on demand. Especially when they just provide key-value pairs I see no reason to duplicate that functionality and memory in a own state variable. I think the extension registry is optimized for performance already, so string lookups into the IConfigurationElement should be fairly quick? The LTK refactoring participants are also not dynamic aware, btw. I have written myself an ExtensionPoint class which allows to quickly visit all available extensions and filter them and then work with them. Also I have my own ExtensionRegistry base class that is essentially a tracker as you show in your second sample, and it calls (via reflection) methods on the subclass to actually handle incoming and going extensions like this (for your second sample): @Required({"id", "label")} protected void addKeyword(IConfigurationElement) { } As you can see, my ExtensionRegistry class also verifies that the extension has the required attributes. Which could be extended to add specific constraints to the attributes, such as a regex or type constraint and range constraints. Overall programming dynamic aware is not that difficult at all. It just take a little more extra effort but the gain is great. That StringVariablePresentationManager screams for a refactoring patch then.
Regarding extension I wonder what the best approach should be: Save the extensions in an internal state (a map like in your second example). Or query the available extensions on demand. Especially when they just provide key-value pairs I see no reason to duplicate that functionality and memory in a own state variable. I think the extension registry is optimized for performance already, so string lookups into the IConfigurationElement should be fairly quick?
The LTK refactoring participants are also not dynamic aware, btw.
I have written myself an ExtensionPoint class which allows to quickly visit all available extensions and filter them and then work with them. Also I have my own ExtensionRegistry base class that is essentially a tracker as you show in your second sample, and it calls (via reflection) methods on the subclass to actually handle incoming and going extensions like this (for your second sample):

@Required({“id”, “label”)}
protected void addKeyword(IConfigurationElement) {
}

As you can see, my ExtensionRegistry class also verifies that the extension has the required attributes. Which could be extended to add specific constraints to the attributes, such as a regex or type constraint and range constraints.

Overall programming dynamic aware is not that difficult at all. It just take a little more extra effort but the gain is great.

]]> By: A.Sokolowski http://eclipsesource.com/blogs/2009/07/23/osgi-dynamics-and-eclipse/comment-page-1/#comment-2390 A.Sokolowski Fri, 24 Jul 2009 05:17:15 +0000 http://eclipsesource.com/blogs/?p=2148#comment-2390 Now, this is the explanation! At least I understand the reasons for the dialog, and will not complain about it any more :) But still, the massage could say more clearly, or rather say the same thing in the way, that makes an user to feel more comfortable, something like that: "If you are not sure what to select, just restart Eclipse". Now, this is the explanation! At least I understand the reasons for the dialog, and will not complain about it any more :)
But still, the massage could say more clearly, or rather say the same thing in the way, that makes an user to feel more comfortable, something like that: “If you are not sure what to select, just restart Eclipse”.

]]>