How to instruct P2 to install an additional (older) version

[laeubi]

I have the case that I want to install two bundles in different versions, but P2 refuses to install both items (they are not marked as singeltons), is there a way to make P2/Eclipse to install two versions in parallel?

[mickaelistria]

I think you can achieve it with the p2 director CLI.

[merks]

Here's an example where two bundles of different versions are installed:

Here are more examples:

Generally if you want two bundles of different versions both installed, something must require that. E.g., two different features that include the bundle but of different versions, or in JDT's case, one feature that includes both bundles. Another possibility is when there are bundles that must be installed and these require using version ranges that are not satisfied by a single bundle leading to both versions needing to be installed. In all cases, for there to be two versions of a bundle, there must be at least two requirements and those requirements cannot be satisfied by a single version.

[laeubi]

Okay, maybe it was not clear enough, but I require a solution that can be used by a user using Eclipse P2 UI, I know I can archive this for example to create a feature that require both exact versions but what I want is that I have an update site and a user can select to have Version 1, 2, 3, 4 or any combination like 2,4 ... this is currently refused by P2 because it says I can't install for example 2 because a newer version is already installed :-(

[laeubi]

You can also choose bundles, you can try it out with this update site: https://download.eclipse.org/technology/m2e/snapshots/latest/

1. Update the eclipse to the latest m2e version
2. then open the install dialog and make sure "show only latest version" is disabled and "Hide what is installed", then under Maven Runtimes you should see two items one that is already installed and an older version:
   

The select the older version and try to install it, and P2 will complain that it needs to search alternatives, where the only thing offered is

"M2E Embedded Maven Runtime (includes Incubating components)" will be ignored because a newer version is already installed.

The goal is that the user can install as many runtimes as he want to later be able to select what a run should use (the screenshot was taken by installing the bundle directly into OSGi without P2):

[merks]

I see. I guess that’s possible only if you mention a bundle which is a bit unusable. So it seems p2 does not like choosing multiple root IUs with only version differences probably because it typically expects features as the choices for which it makes no sense. So are you looking for something that works today? I think only different features will work today. E.g., a 3.8.x feature and a 3.9.x feature. Multiple non-singleton roots can maybe be made to work but perhaps not easily.

[laeubi]

The problem is that the we need to rename the feature each time, what is a bit annoying and error prone, maybe one can make a p2.inf that chooses a different p2.iu.id but keep the bundle name intact but I'm not sure if this might confuse others, or one can construct dummy UI that requires that bundle, but again I fear it might become fragile if we forget to update it to match the bundle version, so in general I want P2 to tell that this IU is "multiple-root" or something...

[merks]

The more I think of it the more I think multiple versions of the same IU as root requests seems not so workable. What could/would check for updates do when 3.9.200 becomes available? Update all of them to the one new version? Update none of them? Neither seems ideal/correct. Wrapping in 3.8.x/3.9.x features would allow sensible updates to both/either versions.

[laeubi]

With package managers (e.g. apt / rpm) there is usually a concept of "explicit installed" and "installed indirectly", explicit items are kept, and indirect items are maybe uninstalled/updated if their requiring package is updated.

e.g there will never be an update for 3.9.2, there will be an update of m2e.core feature that indirectly requires a newer version and in that case I would expect it to install an additional bundle, that would actually be desired so people can still use the old runtime if they find there are regressions between maven versions, and this will become important for maven 4 as it is a major release (and 3.9.x already has some breaking), in that case we will have users that need to stay at maven 3.x and some that want to use maven 4.x, even though it is currently not the case we should be prepared for that as maintaining two independent releases of m2e seems not something we can offer...

[mickaelistria]

I think the overall approach of using multiple versions to contribute distinct features is dangerous. p2 doesn't understand it well as you can see, the extension registry neither, as it's the usual interpretation of a version that newer versions of X is meant to be used in place of older version of X when possible.
Usually, the pattern for such case is to have bundles with different ids, eg org.eclipse.m2e.maven.runtime_3_8_3, org.eclipse.m2e.maven.runtime_3_9_2 and so on, to highlight that one is not necessarily a full substitute for te other.

[laeubi]

I think the overall approach of using multiple versions to contribute distinct features is dangerous.

It is actually not, that is usual OSGi practise and already used as shown by @merks

p2 doesn't understand it well as you can see

I can't see that P2 does not understand it, it just seem to be a specific behavior of the update/install action

the extension registry neither, as it's the usual interpretation of a version that newer versions of X is meant to be used in place of older version of X when possible.

Extension registry is not used, beside that such bundles need to be singeltons, what is not the case here.

Usually, the pattern for such case is to have bundles with different ids

This is more a hack/workaround, I won't call this "usual" from the OSGi point of view, as OSGi can handle different versions without any problem.

to highlight that one is not necessarily a full substitute for te other.

It is a full substitute, just a different version, no one would want to have gson or alike to choose a version in the name.

[mickaelistria]

OSGi can handle different versions without any problem. [,,,] OSGi can handle different versions without any problem.

What happens with OSGi services in this case? Can multiple versions of a bundle contribute services and all those services be available, or are only services from only 1 version loaded?

[laeubi]

All versions are published (even though the bundle here does not contain any), but a consumer will only discover these services that are compatible with its imports, or has to explicitly opt-in for getting even incompatible services see:

https://docs.osgi.org/javadoc/r4v42/org/osgi/util/tracker/ServiceTracker.html#open(boolean)

So lets say I have a consumer that import package version 1, and one that imports version 2, and two providers in version 1, 2 then each of the consumers will get the services from its matching version, so you have 2 similar services, but each consumer will only see one by default.

[merks]

If the only solution seems to be to design, specify, implement, and support new concepts (a new type of p2 root request) for such a use case you might want to consider if you really would be better off as @mickaelistria suggests. I.e., include the version in the symbolic name, install any combination of these, never update them, and it all works today.

[laeubi]

I have now used some p2.inf magic recently added to Tycho to generate some artificial units one can install that then pull in the bundle:

• Use p2.inf to generate installable maven runtimes and add release note eclipse-m2e/m2e-core#1449

This now allows to install additional runtimes, the only drawback is that if there would be a newer runtime bundle it would not be updated automatically as already mentioned here:

• Support "deep" updates #173

and one can't really uninstall a runtime that way because uninstallBundle touchpoint currently only allows uninstall a bundle with a fixed version while we would need a range here.