Community
Participate
Working Groups
Build ID: Eclipse 3.6.1 (M20100909-0800) In the context of our Eclipse-based product, we have a couple simple commandline apps which do not require a Workspace but should run very fast. During testing, we noticed that the ResourcesPlugin is activated through Preferences, even though we want to avoid this. This is a severe problem, since activating Resources not only impacts Performance but has a couple other consequences such as initializing a Workspace where there shouldn't be any. We assume that similar problematic behavior is also shown by some standard Eclipse commandline apps, such as the p2 director or the p2 mirror app. See attached backtrace: activation happens the first time a Preference node is queried, because of this code in PreferencesService line 37ff: // cheat here and add "project" even though we really shouldn't know about it // because of plug-in dependencies and it being defined in the resources plug-in private static final String[] DEFAULT_DEFAULT_LOOKUP_ORDER = new String[] {"project", //$NON-NLS-1$ InstanceScope.SCOPE, // ConfigurationScope.SCOPE, // DefaultScope.SCOPE}; Any Preference query that falls back to the default lookup order will activate the Resources plugin because it contributes the project scope - even though accessing the project scope doesn't make sense while the Resources plugin isn't active (since there cannot be a proper project scope anyways). Suggested solution: Remove the hardcoded "project" String from the DEFAULT_DEFAULT_LOOKUP_ORDER, and add API by which the Resources plugin can register its scope into the DEFAULT_LOOKUP_ORDER when it is activated. Workaround: ?
Created attachment 183199 [details] Backtrace showing ResourcesPlugin activation
Marking as major until a workaround is known.
The code was initially done this way to try and preserve backwards compatibility with the previous preference mechanism. Yes, this is a known issue that other people have come across before; it became apparent once RCP became more popular and people started creating real RCP apps that didn't need the resources bundle. In previous cases people had been shipping products that included the resources bundle but didn't require it so the solution for them was to trim their product configuration and only ship the bundles that were actually needed for their product. It sounds like in your case that you have a product (like the SDK or built on top of the SDK etc) which includes/needs the resources bundle but also you ship some headless applications which don't require it and in this case actually are a hinderance if it is around. Like you mention, a possible solution would to have the resources bundle register itself if it is present. This is something which can be investigated. A workaround in the meantime would be to have a product configuration file for your headless application and in the product config strip out the bundles which it doesn't need/want.
Another workaround would be to change the code which is calling the PreferencesService to not use the default lookup order by specifying the preference scopes that it is searching.
Thanks for the response, DJ. Creating a special configuration for our headless apps is one Workaround that we have considered as well. With p2 though, it doesn't seem trivial how to make this happen (ie how do we generate a proper configuration area, profile, bundles.info ... that would also work in a multi-user scenario where the configuration area is read-only?). Any hints / pointers for this would be appreciated! Changing the call which accesses prefs isn't possible in our case since the actual call happens as a side-effect of activating core.variables (see attached backtrace). One idea for a workaround that I had was calling PreferencesService#setDefaultLookupOrder() for those keys that we know we'll need, such that we mask resources before it gets default-activated. But the problem here is figuring out what preference keys will be accessed in the future by all dependent plugins.
Created attachment 183236 [details] patch Tom and I talked and another quick fix (rather than creating new API) would be to take advantage of the x-friends directive. The resources bundle is already a friend of the preferences so for now we can have the resources bundle modify the default default lookup order on startup. The attached patch is untested. If you think real API should be introduced to do this, then we can discuss that option.
Whow, that was fast :) Since the original problem can only happen for core.resources, the patch looks good to me leveraging x-friends. I'm not sure how fast we'll be able to try out and verify the patch against our real headless apps, but again, it looks good to me. I'd probably add some Javadocs to the setDefaultDefaultLookupOrder() method, indicating that this has specificially been introduced for the "project" scope contributed by core.resources. Since improper use of the new public method would bear the risk of concurrency issues (stepping on somebody else's changes).
Created attachment 183252 [details] patch (In reply to comment #7) > Whow, that was fast :) > Internal email is currently down so the bugs which are discussed in the Eclipse bugzilla get priority. :-) I've added more comments to the #set method like you suggest. I will wait for Szymon to comment before releasing anything.
Created attachment 187200 [details] patch Updated patch.
Latest patch has been released to HEAD.
Thanks for the fix, DJ! Any chance backporting this to 3.6.2 or am I asking too much? It would be an important fix for our RCP, and it looks like we'd have to for Eclipse and apply the patch to our fork if we don't get this from the mainstream.
Created attachment 187240 [details] patch for 3.6.x stream Sorry, but we're a little late into the R3.6.2 lock-down to release it. (I should have looked at it last week) Here is a patch against the R3_6_maintenance stream though, hopefully that helps you.
Note I didn't make any bundle version changes in the patch so they will still have to be done.
I have file bug 337693 to request backporting the fix in attachment 187240 [details] into the 3.6.2+ maintenance stream, such that we can easily adopt it in our product. This fix is important for us since the resources plugin activation drags in a whole lot of extra dependencies which we need to avoid in some of our UI-less commandline utilities.
