Updating a touchpoint action and calling it calls the previous version of the action

[axelbstein]

When updating a custom touchpoint action and calling it during the installation process, the previous version of the action gets called instead of its new version installed with the update. The p2.inf advice instructions don't use the newly updated plugin, but the currently installed version.

This is in contrast to installing the action for the first time (let's call this version v0), where the newly installed action gets invoked during the installation. However, an update will invoke the previous version of the action (v0) from the initial installation, not the newly updated one (v1). An update after that will invoke the previous version (v1), not the currently updated one (v2), and so on.

I've uploaded an example project that reproduces this problem:

https://github.com/axelbstein/com.project.root

Setting metaRequirements.0.range=1.0.0.$qualifier$ results in a dependency conflict as mentioned in the example.

What do the Equinox developers do when they introduce a new action to the Equinox touchpoint action plugins (org.eclipse.equinox.p2.touchpoint.eclipse and org.eclipse.equinox.p2.touchpoint.natives), and need to call that action in the same update from a p2.inf? Having metaRequirements.range=$version$ leads to the dependency conflict mentioned earlier, while a permissive range will give the error that the action could not be found (because it doesn't exist yet in the currently installed plugin).

[merks]

FYI, I will try to look at this as soon as possible.

[axelbstein]

@merks, I've uploaded your previous suggestion of using an independent bundle to this branch (diff) and wrote a brief note about it.

[merks]

So you tried what I suggested and that worked?

Be careful with using $qualifier$ or $version$ because these expand to the version of the containing bundle not to the version of the referenced bundle.

Here I hacked it to hard code a certain qualifier:

So the build produces that version

But the requirement expands to the feature's qualifier and is wrong:

My advice would be to specify the lower bound without a qualifier, and to change all these three places (versions) whenever you change the action in such a way that it must be updated before the feature is updated:

Use 0.0.0 in the category.xml so it just replaces it with whatever version in is built.

So the feature should end up like this:

Where nothing locks in the older version of com.project.plugin. And you can force a "metadata" update of com.project.plugin by incrementing the version and specifying that this new version must be installed prior to proceeding with the rest of the installation.

[merks]

@axelbstein

Any updates? I'm hoping you are successful!

[merks]

I'm going to interpret silence as success.

[axelbstein]

Hi @merks, I've implemented your solution and uploaded it to this branch. The solution works as long as only the feature is selected for installation and not the bundle under "Uncategorized".

I have the following questions and remarks:

1. When the original feature from the main branch that includes the plugin is already installed on the Eclipse platform, installing the solution with the independent bundle over it does not work and results in the same conflicting dependency error seen earlier:

Your original request has been modified.
  "Feature" is already installed, so an update will be performed instead.
The actions required to successfully install the requested software are incompatible with the software to install. 
  Cannot complete the install because of a conflicting dependency.
    Software being installed: org.eclipse.equinox.p2.engine.actions.root.epp.package.rcp 1.0.0.1723027348496
    Software currently installed: Feature 1.0.0.202408071040 (com.project.feature.feature.group 1.0.0.202408071040)
    Only one of the following can be installed at once: 
      Plugin 1.0.1.202408071043 (com.project.plugin 1.0.1.202408071043)
      Plugin 1.0.0.202408071040 (com.project.plugin 1.0.0.202408071040)
    Cannot satisfy dependency:
      From: Feature 1.0.0.202408071040 (com.project.feature.feature.group 1.0.0.202408071040)
      To: org.eclipse.equinox.p2.iu; com.project.plugin [1.0.0.202408071040,1.0.0.202408071040]
    Cannot satisfy dependency:
      From: org.eclipse.equinox.p2.engine.actions.root.epp.package.rcp 1.0.0.1723027348496
      To: org.eclipse.equinox.p2.iu; com.project.plugin 1.0.1

In order to work, this solution needs to be installed as an independent bundle from the start, and kept as such. Furthermore, the plugin should never be selected for installation, or this will lead to a conflicting dependency error after another update. Since a generalized solution covering the problem scenario described in the issue where the plugin is already installed was not proposed so far, closing the issue as completed does not seem appropriate to me.

2. What do the Equinox developers do when they introduce a new action to the P2 touchpoint action plugins (org.eclipse.equinox.p2.touchpoint.eclipse and org.eclipse.equinox.p2.touchpoint.natives) or update an action's behavior, and need to call that action in the same update? Has this scenario not been encountered yet? Are new actions only shipped with new releases and not via updates? As noted earlier one is faced with either P2 using the currently installed action, or a dependency conflict.

3. What is the advantage of the solution without the qualifier vs. the earlier solution with the qualifier, which also worked? With the previous solution the qualifier seemed to automatically force the use of the latest bundle. Is it about the finer manual control of which version we want installed?

4. How did you activate the "Installable Unit Details" view you showed in screenshots? I am unable to find it.

Thanks.

[merks]

It's a challenge to come back to an issue after months of silence. It's not as if I keep every detail of every issue in my head forever...

---

1

If you include a bundle in a feature you will never be able to update that bundle without also updating the feature that includes it. If you want that bundle to be a meta requirement for updating anything (such as the feature), then you have defined a set of requirements such that there is no solution to the problem. It must be possible to update the meta-required bundle. That implies there must be nothing installed that restricted/excludes the updated version of the bundle.

As for closing an issue, your last comment was in March. I'm not sure how long you expect an issue to just sit inactive. It's also not clear what you are expecting to have fixed. I don't believe anything is broken and this is more of a question than a problem report. In any case, the p2 framework is very complicated and there are few people who understand it well enough to fix problems. So if you want a really hard problem fixed, you should consider how that will get done. Will you try to fix it? Will you expect that I find some free time to fix a problem on your behalf? (It's also rather hypothetical because I don't think anything is broken.)

---

2

Indeed as far as I know 2 ever happens. One would plan ahead for new things and make them available before starting to use them. In any case, it's hypothetical.

---

3

If you're happy to use the qualifier of the feature, that's fine, if it work, but as I pointed out, that is not the qualifier of the bundle, so how that works, I can't imagine. I expect that if your meta-bundle does some funky new thing, that it should have a new version like 1.0.1 minimally and that you'd need to change the p2.inf of the feature to specify/require that new version.

---

4

This button will show all the IUs rather than just categorized things: