Home » Eclipse Projects » Equinox » p2.inf instructions don't use newly updated plugin, instead use the currently installed version(During the update of a custom touchpoint action, the previous version of the action gets called instead of its new version.)
| p2.inf instructions don't use newly updated plugin, instead use the currently installed version [message #1863658] |
Mon, 19 February 2024 14:09  |
 Axel Stein
Messages: 10
Registered: February 2024 |
Junior Member |
|
|
I am trying to update a custom P2 touchpoint action that is called at the configuration phase with a p2.inf file. However, I noticed that during the update process, the old version of the custom action gets called instead of the new version installed with the update.
This is in contrast to when I install the action for the first time (v0), in which case 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.
Is there some way to make P2 invoke the action from the update and not the previous version that is currently installed? By the time we reach the Configure phase we should already be past the Install phase. Since it's possible to invoke the action during its first installation it should also be possible to do this in the update. I have tried using metaRequirements, range, and other instructions, without success.
My code looks as follows:
Plugin: com.project.plugin
└─+com.project.plugin.actions
└──MyCustomAction.java
plugin.xml:
<plugin>
<extension
point="org.eclipse.equinox.p2.engine.actions">
<action
class="com.project.plugin.actions.MyCustomAction"
name="myCustomAction"
touchpointType="org.eclipse.equinox.p2.native"
touchpointVersion="1.0.0"
version="1.0.0">
</action>
</extension>
</plugin>
META-INF/p2.inf:
provides.0.namespace=com.project.plugin
provides.0.name=myCustomAction
provides.0.version=1.0.0
Feature: com.project.feature
p2.inf:
metaRequirements.0.namespace=com.project.plugin
metaRequirements.0.name=myCustomAction
metaRequirements.0.range=1.0.0
instructions.configure=com.project.plugin.myCustomAction();
feature.xml:
<feature
id="com.project.feature"
label="Feature"
version="1.0.0.qualifier"
provider-name="Provider">
<plugin
id="com.project.plugin"
download-size="0"
install-size="0"
version="0.0.0"
unpack="false"/>
</feature>
[Updated on: Mon, 19 February 2024 17:23] Report message to a moderator |
|
| | | | | |
| Re: p2.inf instructions don't use newly updated plugin, instead use the currently installed version [message #1863738 is a reply to message #1863685] |
Fri, 23 February 2024 19:20  |
Axel Stein
Messages: 10
Registered: February 2024 |
Junior Member |
|
|
Your suggestion worked. I removed the bundle from feature.xml and added it to category.xml and now upon installing the update it executes the newest instructions from version 1.0.0.$qualifier$ of Plugin. I don't even need META-INF/p2.inf in Plugin anymore.
This works in my toy example where the plugin is installed for the first time, however in my application I get dependency problems from the other plugins in feature.xml that import this plugin.
Is there some way to keep the bundle in feature.xml and force it to use the latest version of Feature, with the p2.inf with metaRequirements.range=1.0.0.$qualifier$ placed in another feature (CallingFeature) that has no other dependencies on Plugin? P2, however, doesn't just override the previous Feature, instead giving me the error below when, for example, going from v732 to v956. This dependency conflict seems trivial to me since I just want the latest version. What is going on?
Your original request has been modified.
"Feature" is already installed, so an update will be performed instead.
"CallingFeature" 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.DefaultProfile 1.0.0.1708587975572
Software currently installed: Feature 1.0.0.202402220732 (com.project.plugin.feature.feature.group 1.0.0.202402220732)
Only one of the following can be installed at once:
Plugin 1.0.0.202402220956 (com.project.plugin 1.0.0.202402220956)
Plugin 1.0.0.202402220732 (com.project.plugin 1.0.0.202402220732)
Cannot satisfy dependency:
From: Feature 1.0.0.202402220732 (com.project.plugin.feature.feature.group 1.0.0.202402220732)
To: org.eclipse.equinox.p2.iu; com.project.plugin [1.0.0.202402220732,1.0.0.202402220732]
Cannot satisfy dependency:
From: org.eclipse.equinox.p2.engine.actions.root.DefaultProfile 1.0.0.1708587975572
To: org.eclipse.equinox.p2.iu; com.project.plugin 1.0.0.202402220956
|
|
| |
| Re: p2.inf instructions don't use newly updated plugin, instead use the currently installed version [message #1863799 is a reply to message #1863748] |
Tue, 27 February 2024 12:06 |
Axel Stein
Messages: 10
Registered: February 2024 |
Junior Member |
|
|
By the "meta" plugin you mean the com.project.plugin that I am trying to install, correct?
I already removed any reference to com.project.plugin except for metaRequirements. I noticed the following:
- When com.project.feature has no metaRequirements, the feature installs. When I include the metaRequirements to com.project.plugin, I get a dependency conflict like in this previous message. NB: com.project.feature and com.project.plugin already exists in the application, with previous versions.
- Creating a copy plugin com.project.plugincopy and a new feature com.project.dummyfeature with just metaRequirements allows me to install com.project.plugincopy the way I want, with the newest version being installed and executed every time, and with no dependency conflicts. Unfortunately it seems bad practice to me to pollute my project with new workaround features and plugins every time I need a new action.
What I am trying to solve is the problem in item 1. The metaRequirements are somehow causing a dependency error/version conflict. Removing the metaRequirements solves the conflict, but doesn't give me the action. There is no reference to com.project.plugin in feature.xml that to my knowledge could be causing the conflict.
I also noticed that when I make metaRequirements.0.range=[0,2], the version conflict disappears but the latest action is not executed - like in the OP. But when I specify 1.0.0.$qualifier$ as the version I get the dependency error. The combination of com.project.plugin with metaRequirements.0.range=1.0.0.$qualifier$ for some reason gives dependency problems. Any help in solving this would be appreciated.
[Updated on: Tue, 27 February 2024 13:09] Report message to a moderator |
|
| | |
| Re: p2.inf instructions don't use newly updated plugin, instead use the currently installed version [message #1863887 is a reply to message #1863877] |
Mon, 04 March 2024 08:46 |
Ed Merks
Messages: 33222
Registered: July 2009 |
Senior Member |
|
|
This is just not a commonly used feature. And, as I said, if the version ranges are narrow enough to force an update to the metada-required bundle but are also permissive enough that installing (updating to) the new meta-required bundle will not cause a conflict with any other currently installed bundle or feature (because these other things all have a range that permits the new higher bundle version), then I would expect and hope that the meta-required plugin is installed/updated and used for the rest of the update process. But given I have to guess as the exact details of what you are doing, and given this is not a commonly used feature, i.e., not a feature used by the Eclipse SDK nor by any of the Eclipse Packages on the download pages, I don't think you will find anyone with detailed experience to answer the question based on their own use of this feature. Even finding someone with the necessary expertise to hire will be a challenge...
I can try to help on the forum, but if you say something leads to a dependency conflict then I need exact details of what versions of what bundles and feature are installed along with what version ranges are on all their requirements, as well as versions are you trying update to along with their version ranges. Even just showing the conflict error message will provide tea leaves to read which is better than the current shadows...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Fri Oct 04 00:17:47 GMT 2024
Powered by FUDForum. Page generated in 0.49807 seconds |
] 
Search
Help
Register
Login
Home
