| Auto update with setup task when p2 site changes [message #1827458] |
Thu, 14 May 2020 22:23  |
 Aleksei Airapetov
Messages: 13
Registered: December 2019 |
Junior Member |
|
|
Hello,
I am trying to make my Eclipse-based IDE update work.
For now the process I have organized looks like this - I have feature-based product which is used to build a p2-update site using Tycho. The produced p2-site is then published to a remote storage. I also have a .setup file which includes all features from my product. Installation with Eclipse Installer using this setup works as it should.
Problems start when I rebuild a p2 site and upload it to the same remote storage so it replaces old one. The version of my features and product has a different build number (let's say the new features have version 0.1.0.2, while the old ones have version 0.1.0.1; I also tried to raise the maintenance segment of the version 0.1.0 -> 0.1.1). I expect my installation to report updates after restarting and/or selecting an option "help -> perform setup tasks" but Eclipse updater reports that there are no available updates after the setup task execution. (although a newly installed product will contain the new version of the features from the new p2).
I am also aware of "installMode=root" option for features definition in product but I decided not to use it because it seems that this is the wrong approach since, as I understand it, the product should be the only root installable unit (in addition, then this parameter would have to be added for all features, which led me to other errors when trying to update). I also don't specify version ranges for the features in my setup file.
I also tried to debug Oomph and p2 plugins and I realized that the update mechanism sees the new version of features and forms pairs of conflicting
IUs, but as far as I understand, at this step:
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.director/src/org/eclipse/equinox/internal/p2/director/OptimizationFunction.java#n75
the choice is made in favor of already installed old versions of the features.
Also during the update check process a profile change request is formed in the following format:
==Additions==
artificial_root 1.0.0.v1589443526045
==Removals==
<some of my old version features here>
which seems to be then ignored (maybe it works as it should, just looks a little strange to me) because the setup task execution ends with a message that there are no updates available.
So the question is - is the "perform setup tasks" mechanism intended for what I'm trying to do and if so, could you help me understand where I make a mistake?
|
|
|
| Re: Auto update with setup task when p2 site changes [message #1827467 is a reply to message #1827458] |
Fri, 15 May 2020 04:21  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This sounds strange. I.e., we have many products based on the EPP packages in the generated catalog and when there is a new release (or a new milestone), the p2 Director task finds updates and installs them. So I do generally expect that this mechanism will find and install available updates. So what you describe sounds unexpected.
What I would try in this situation is to change my Product setup such that it explicitly requires the newer version of the product, i.e., set the lower bound such that it excludes the already-installed version of the product. Then the p2 Director task will either install it, or it will fail, and if it fails, then you'll better understand whether this is some conflicting/missing requirement that can't be satisfied by the newer version of the product. Such a conflict could lead p2 to favor using the older version that does not lead to conflicts...
Also note that installMode="root" is probably not what you want. When this is specified, the Tycho build of the product will install such features, but the p2 metadata for the product IU will not contain requirements on the features. I.e., the purpose of this mode is to allow the user to uninstall these features and that's of course only possible if the product doesn't actually require the feature.
I'd also use the Repository Explorer to look very closely at the product IU to see exactly how its requirements look. I.e., I expect a new version of the product with at least a new qualifier and it will typically have exact version range requirements on the features also restricted to the new qualifier.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Auto update with setup task when p2 site changes [message #1827573 is a reply to message #1827566] |
Mon, 18 May 2020 14:07 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Yes, there should be no need to specify requirements on anything that is transitively required anyway. Generally the product IU, unless you use "root", will require specific versions of the features.
What's in the Help About comes from the plugin that has <extension id="product" point="org.eclipse.core.runtime.products"> in the plugin.xml. If this is old, this suggests that an old version of that plugin is still installed. But you can verify that in the Plug-ins tab and that plugin should be a singleton because it has a plugin.xml.
Features themselves aren't singletons, so you can have more than one version installed. I think you mentioned seeing duplicates on the Feature's tab What about the Plug-ins tab? Do you see duplicates there? Most plugins are typically singletons because a great many contribute plugin.xml extensions and must be singletons and because most things just don't make sense to be installed multiple times. So if you ensure that those plugins that should not be installed more than once (probably all of them) are marked as singletons, then the feature's that include those bundles also can't be installed more than once. You do that, for example, like this:
Bundle-SymbolicName: org.eclipse.oomph.setup.installer;singleton:=true
From experience with many other setups, including the platform setup where it installs the Platform SDK product, I regularly just run Perform Setup Tasks, and it will update to the latest platform IBuild, so this should all just work without specific version ranges in the setup...
The logging in the Updater listens to all information produced from all jobs and tries to filter out noise. But it's not always successful, so some noise from some other jobs that are running may show through.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Auto update with setup task when p2 site changes [message #1827619 is a reply to message #1827573] |
Tue, 19 May 2020 12:34 |
Aleksei Airapetov
Messages: 13
Registered: December 2019 |
Junior Member |
|
|
I've been inspecting the "Plugins" tab for a while and also tried to debug updating process - if versionRange is present for the product the update seems to work as it should - just when you restart the IDE, it seems to perform some additional operations for about 5 minutes. After that, the help -> about tab shows the new version of the product. Also in the "Plugins" tab I didn't find any duplicates of my plugins either before or after the update (only a few duplicates of minor third-party plugins).
Updating without specifying versionRange still doesn't work.
But what's strange is that I don't see my own features in the "Features" tab (yes, I was talking about duplicate features, but I could only see them in the "Installed software" tab, not in the "Features" tab) - there are only "org.eclipse..." ones. Is this to be expected?
The problem with the logs like "Configuring <plugin>" is that because of this, the IDE requires a restart after each run of perform setup tasks operation (even if there were no updates).
I also tried debugging this problem and found that in this place
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.director/src/org/eclipse/equinox/internal/p2/director/OperationGenerator.java#n66
when planning update operations, the fromIU field does not have the "tooling.osgi.bundle.default 1.0.0" "fragment", but the toIU field does which causes the" Configuring " operation of this plugin (sorry for clumsy explanation, I just don't know the terminology of p2's internal workings).
I have also previously observed similar behavior for a plugin fragment, for which the host plugin was absent (it also constantly called "Configuring" logs). But now the logs contain not only fragments but also plugins, both mine and org.eclipse ones. Can this problem be related to the absence of my features in the "Features" tab?
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.01812 seconds
] 
Search
Help
Register
Login
Home
