Add apache.aries.spifly.bundle to list of recommended auto-start bundles

[HannesWell]

Now that org.apache.aries.spifly.dynamic.bundle is required by the Eclipse-SDK, like for example org.apache.felix.scr and since it has to be auto-started (just like felix.scr), aries.spifly should be added to the list of recommended auto-start bundles.

My best guess for the start-level was to choose the same like for felix.scr since both serve a similar purpose (connect services in a OSGi runtime).
Does anybody have a better idea? @tjwatson, can you say what to choose best?

[merks]

So I should soon expect to see it in the platform's *.product files and all downstream products will generally be affected? What happens if it's missing, as will of course very often be the case?

[github-actions]

Test Results

     246 files  ±0       246 suites  ±0   1h 0m 34s ⏱️ - 7m 41s
  3 299 tests ±0    3 274 ✔️  - 1  24 💤 ±0  1 ❌ +1 
10 194 runs  ±0  10 121 ✔️  - 1  72 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit b7360c2. ± Comparison against base commit 7f49462.

♻️ This comment has been updated with latest results.

[HannesWell]

So I should soon expect to see it in the platform's *.product files and all downstream products will generally be affected? What happens if it's missing, as will of course very often be the case?

If aries.spifly is not included it will not added once #643 is merged (it will also not be listed in the pop-up that lists all entries that will be added).

Furthermore this has only an effect if one hits the Add Recommened button in the Configuration section of a Product's editor, so nothing happens automatically:

[laeubi]

As org.apache.aries.spifly.dynamic.bundle uses the weaving hook ist should be started as soon as possible even before the ds bundle so so I would use level 1.
In general for products I think it would be better to even use the framework extension org.apache.aries.spifly.dynamic.framework.extension to make sure it is always loaded before anything else.

[HannesWell]

As org.apache.aries.spifly.dynamic.bundle uses the weaving hook ist should be started as soon as possible even before the ds bundle so so I would use level 1.

From that point it would make sense. What makes me worry about this a bit is that the p2.simpleconfigurator also starts with 1 and I don't know if it could be harmful if spifly starts before that bundle.

In general for products I think it would be better to even use the framework extension org.apache.aries.spifly.dynamic.framework.extension to make sure it is always loaded before anything else.

Yes I tried that one as well a while ago already, but PDE then complained with validation errors during launching. I have the intention to make that work later.
Additionally framework extensions can be difficult to manage, because you either have to specify an absolute path or it has to be co-located next to the o.e.osgi system-bundle and it can be tricky to choose a good value for a product that works if one builds the product (with Tycho) and at the same time works if one launches the product in the IDE with PDE.
When both, o.e.osgi and the framework-extensions are both in the TP the jars are usually co-located, so this is not a problem, but if either one is in the workspace and the other in the TP, then they are not and I didn't found a better solution than adjusting the launch-config manually (I have that case in my day-job were we use our own framework-extension).

I already considers to enhance PDE to detected if the Product's VM-arguments contain a framework-extension with a relative reference:file: URL (i.e. -Dosgi.framework.extensions=reference:file:<artifact-name>), to then replace it with a variable that resolves to the absolute path of the extension, when creating a launch-config from the Product.
Ideally this would use a variable that works for bundles in the workspace and in the TP (havn't checked if one exists). Then we would have covered both cases of framework-extension in the workspace or o.e.osgi in the workspace.

[laeubi]

From that point it would make sense. What makes me worry about this a bit is that the p2.simpleconfigurator also starts with 1 and I don't know if it could be harmful if spifly starts before that bundle.

This should not be a problem unless p2.simpleconfigurator require spyfly.

In the end it would be good if we can make framework extensions more convenient.

[tjwatson]

Additionally framework extensions can be difficult to manage, because you either have to specify an absolute path or it has to be co-located next to the o.e.osgi system-bundle and it can be tricky to choose a good value for a product that works if one builds the product (with Tycho) and at the same time works if one launches the product in the IDE with PDE.

For very advanced Equinox-specific framework extensions that a want to extend Equinox specific things from the Equinox adaptor this is true. For example, implementing a org.eclipse.osgi.internal.hookregistry.StorageHookFactory<S, L, H>. But here Aries SPI-Fly framework extension is a standard OSGi framework extension that should work installed from any directory.

[laeubi]

@HannesWell do we still need/want this?

[HannesWell]

@HannesWell do we still need/want this?

The unification yes, adding aries-spifly probably not hoping that I will soon complete the Equinox implementation of the Mediator service.