Community
Participate
Working Groups
Build Identifier: I20110127-2034 As a follow up to the discussion http://www.mail-archive.com/p2-dev@eclipse.org/msg00203.html here's a patch which makes usage of profile preferences optional based on optionally imported packages. The patch introduces a plug-ability mechanism and no functional changes. In Eclipse scenario there should be no difference in behavior since o.e.e.preferences bundle is presented and optionally imported packages will be wired and treated in the same way as if they were mandatory. When p2 is used standalone it's up to the end user to decide whether to include preferences or not depending on his needs. Reproducible: Always
Created attachment 189607 [details] Optional profile preferences
I'll take a look at this. We did something similar in the preferences bundle so it can behave nicely when the extension registry isn't available.
Katya, just curious if your patch worked without preferences around? It seems to me there would still be some class load errors. (and I noticed an extra "!" in an if clause, etc) The approach that I am taking is to put all preference-related code into a helper class and then in the main code, reference the preference service via a String rather than the class. If the service is not available the skip the code, otherwise just call the helper. For instance: if (helper == null) { Object service = getService("org.eclipse.core.runtime.preferences.IPreferencesService"); if (service == null) return defaultValue; helper = new PreferenceHelper(service); } return helper.getBoolean(key, defaultValue); This is the approach we took in the preferences code (with the registry being optional) and it works well. I think it should work for the p2 cases unless I'm missing something around the way class loads are done. The p2 code around the garbage collector seems to translate well. The code around the repositories is a bit more complicated. (since repo lists are stored in the preferences)
I honestly don't remember all the details of what we agreed to do. At runtime, Is the expectation that there will always be a bundle providing the preference API but no actual service get registered, or that at runtime there is no bundle with those packages?
(In reply to comment #3) > Katya, just curious if your patch worked without preferences around? It seems > to me there would still be some class load errors. (and I noticed an extra "!" > in an if clause, etc) No, I tried to validate the change using p2 tests so I used Eclipse launch configuration where preferences should be presented. I thought I would be able to model preferences absence programatically by returning false from the helper method. Wrong assumption as it seems. Class load errors would disappear if o.e.e.security.storage imports in p2 engine and p2 repository are made optional. The only exception that needs to be discussed is org.eclipse.equinox.internal.p2.repository.Credentials class. On one hand it strongly relies on preference presence since it reads from security preferences essential information. On the other it's used to create ecf connection context. I think it logically belongs to org.eclipse.equinox.p2.transport.ecf bundle. What do you think? I need to know whether this class stays as it is or goes to the ecf bundle before continuing with patch rework. > The approach that I am taking is to put all preference-related code into a > helper class and then in the main code, reference the preference service via a > String rather than the class. If the service is not available the skip the > code, otherwise just call the helper. For instance: > > if (helper == null) { > Object service = > getService("org.eclipse.core.runtime.preferences.IPreferencesService"); > if (service == null) > return defaultValue; > helper = new PreferenceHelper(service); > } > return helper.getBoolean(key, defaultValue); > > This is the approach we took in the preferences code (with the registry being > optional) and it works well. I think it should work for the p2 cases unless I'm > missing something around the way class loads are done. I agree this approach is cleaner though service availability doesn't guarantees that the bundle is wired to all the necessary packages. Maybe declarative services could help to reduce the glue code, I'll think about it. >The p2 code around the > garbage collector seems to translate well. The code around the repositories is > a bit more complicated. (since repo lists are stored in the preferences) As far as I know repositories stored in preferences are used for performance optimization, keeping history, etc - in a sense this information is not critical. Am I wrong? (In reply to comment #4) I honestly don't remember all the details of what we agreed to do. At runtime, Is the expectation that there will always be a bundle providing the preference API but no actual service get registered, or that at runtime there is no bundle with those packages? We discussed two options: - to provide "dummy" preference implementation which doesn't depend on anything unneeded - to isolate calls to preferences in p2 code and these to be skipped when preferences bundle is missing. The main drawback of the first approach is that Preferences interface is located in the same bundle as the implementation used currently in p2 so creating a dummy implementation is pointless if we refer the interface. I remember we agreed that the second option is better because it would be easy to isolate preferences calls and because there won't be need to generate garbage (the dummy impl).
Created attachment 190932 [details] GC bundle changes Here is an example of the types of changes that I was talking about. (patch is untested)
Pascal is more familiar with the interactions between ECF and p2 and maybe can answer your other question.
Sorry for the late reply, but it looks like the credential class can indeed be moved to the ecf transport bundle
DJ, are you still looking into this?
This issue looks dead. Much has changed since this time.
