How can I prevent Eclipse from "Magically" Adding Updatesites?

[ingomohr]

I have project that builds Eclipse based only on mirrored updatesites listed in a respective eclipse.p2.inf file. I build the project with Tycho 4.0.8.

Note: Neither the eclipse.p2.inf file nor the pom.xml nor any other file in the project list the original updatesites.

When I start Eclipse for the first time, it contains not only the mirrored updatesites but also the original updatesite https://download.eclipse.org/releases/latest and also https://download.eclipse.org/technology/epp/packages/latest/.

Since I don't think this is a Tycho-feature but maybe rather a thing in p2, I'm adding the discussion here.

My question is: Is there a way to make sure an RCP-based product solely works on pre-registered updatesite-mirrors?

Here's why this is a problem for me

• When a new Eclipse release has been shipped, Eclipse will suggest not only internal updates we provide on our own updatesites - but also updates from the Eclipse project - which can break compatibility.
• We want to make sure that searching for updates is possible - but in a way that it solely works on certain preregistered updatesites so that we
  • can always grant full compatibility and
  • can perform updates to our plugins and products in a planned way

Thank you in advance for any hint!
Ingo

[merks]

Yes, it's a p2 thing.

An IU's metadata can contain touchpoint instructions to add (or remove) a repository. E.g., search for addRepository in

https://download.eclipse.org/eclipse/updates/4.35-I-builds/I20241223-0230/content.xml

I'm not sure if you have your own product definition or reuse an existing product IU. Product IUs typically do specify the update site from which to update, but often this is done for features a well.

[ingomohr]

Thank you @merks! I think I'll search the documentation on whether there's a way to mirror updatesites w/o those addRepository entries. When in doubt, removing them from the mirrors could be an option, too. I'll give that a try. :)

[Bananeweizen]

Ingo, I build several company products, which all have their own product definition, and none of them magically adds update sites, but only the ones that I list in the product definition (or in myproduct.p2.inf, if one prefers that). We disable the built-in update check via plugin_customization.ini, not sure if that might also be relevant for the final list of update sites.

[ingomohr]

That sounds useful. I read about that removeRepository a couple of weeks ago but didn't give it a try. Will do that - and provide an update here (after Christmas). :)

[merks]

Yes, it's just not clear if one IU wants to add repo x and another wants to remove repo x and both are installed at the same time, which one wins... Is it deterministic? I'm not sure...

[ruspl-afed]

Is it deterministic?

Great question.

[laeubi]

Is it deterministic?

Great question.

The answer is yes :-)

[HannesWell]

Is it deterministic?

Great question.

The answer is yes :-)

IIRC, the instructions are sorted by id/name and applied in that order.

[laeubi]

I just wanted to mention that even though the P2 thing can be made to work it can become tedious as you actually need to check once in a while if something changed (e.g. new things are used or some use versioned sites and so on) and make sure things are applied in the right order.

For the described case

We want to make sure that searching for updates is possible - but in a way that it solely works on certain preregistered updatesites so that we can always grant full compatibility and can perform updates to our plugins and products in a planned way

I would recommend a different approach:

As you have an own product and are in full control of its contents, simply do what P2 would do in a programmatically way and write a litte piece of code that removes all update sites on startup and only retain (or add) the one that you want. This could be a static configured set in code, a system property, a configuration file or you can even fetch the list dynamically from a webserver or active directory.

[ingomohr]

Thank you for the hint and the links, @laeubi!

[ingomohr]

Simply calling removeRepository in the p2.inf file (code snippet below is simplified) doesn't change things. The official updatesites are still there when I start the RCP product. I could imagine that since I didn't add the updatesites (but the content.jars do - and yes, I can second that), those updatesite are not there, yet, to be removed at that point in time.

instructions.configure=\
  addRepository(type:0,name:Eclipse Releases,location:https${#58}//my.mirror/repositories/p2mirror/eclipse_2023-12/eclipse_releases/repository/);\
  addRepository(type:1,name:Eclipse Releases,location:https${#58}//my.mirror/repositories/p2mirror/eclipse_2023-12/eclipse_releases/repository/);\
  removeRepository(type:0,name:Latest Eclipse Simultaneous Release,location:https${#58}//download.eclipse.org/releases/latest);\
  removeRepository(type:1,name:Latest Eclipse Simultaneous Release,location:https${#58}//download.eclipse.org/releases/latest);\

I'll try the other solution where RemoveRepositoryAction is called after the product start.