| Forcing a P2 Update site inside the Eclipse "Update Sites" preferences [message #1784919] |
Thu, 05 April 2018 14:36  |
Eclipse User |
|
|
|
Trying to figure out based on the documentation how to force the Help -> Check for Updates to use our internal mirrors. The preferences still have the 'default' outside URL listed.
I've used the "record" preference option but I still don't see the update URL.
What is the best way to centrally manage the P2 Update URL's , so that it points to our artifactory server. if I missed it in the docs please redirect me.
I need this to be the default for everyone who will be using this model, so if it is a user setup how do I add that to the main package? Each version of Eclipse has a different internal artifactory location due to historical reasons.
|
|
|
| Re: Forcing a P2 Update site inside the Eclipse "Update Sites" preferences [message #1784932 is a reply to message #1784919] |
Fri, 06 April 2018 00:33  |
| Eclipse User |
|
|
|
The preference recorder only records instance-scoped preferences and even the Capture Preferences dialog in the Setup Editor toolbar only shows instance preferences. If you install the Oomph Preferences Management feature, i.e., the IU "org.eclipse.oomph.preferences.feature.group'" , the preferences dialog will include Oomph -> All lPreferences and that has an Edit... button to open the preference explorer editor. That editor has a button in the toolbar to "Keep the editor synchronized with changes to the underlying preference store". This allows you to explore all preferences of all scopes and when any preference is changed, the editor will select the modified preference.
Using this approach you'll see that unfortunately these p2 update URL preferences are stored as profile-scoped preferences. And even worse, the key is an encoded URI of the profile's location on disk. I.e., it depends on where the installation is created. The actual *.pref files are located in the profile's folder so when using a shared bundle pool, they're located in, by default, ~/.p2/org.eclipse.equinox.p2.engine/profileRegistry/*.profile/.data/.settings/*.pref.
Worse still, the content metadata of a product IU can include touch point instructions like this: <instruction key='configure'>
org.eclipse.equinox.p2.touchpoint.eclipse.addRepository(type:0,location:http${#58}//download.eclipse.org/releases/latest,name:Latest Eclipse Release,enabled:false);org.eclipse.equinox.p2.touchpoint.eclipse.addRepository(type:1,location:http${#58}//download.eclipse.org/releases/latest,name:Latest Eclipse Release,enabled:false);
</instruction>
It's all definitely not easy to manage or influence as a result of this overall design. Perhaps the URI(s) you don't want are coming from these touch point instructions and you can change that behavior/result by changing their values in your mirror's metadata (content.jar/content.xml.xz).
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.11607 seconds
Home