|Re: [p2-dev] RCP check-for-update standard behavior|
Thanks guys for your valuable answers.
About dependencies management from feature.xml we do not lock on specific eclipse components versions, maybe we should have a look on that point.
At this time the only stuff we have is on build step, to ensure that the target platform used by Tycho is not volatile; a kind of offline build always reproducible in the future.
Indeed Mickael this question is not related to the Marketplace (just exposed the full story :-)), and I had everything to experiment on my own, having such discussion allows to share experience and I know that, often, several solutions conduct to the same result. Just always trying to pick the most state-of-the-art one.
So I made 2 quick tests, first using Eclipse SDK and our RCP, both based on 2018-12. I added the 2019-03 repository and behaviors were completely different.
- In the SDK the check for update suggested to move to Eclipse 4.11 (with several other updates)
- In the RCP no updates were detected
Fine, that’s what we need.
In the 2nd test I installed a given feature (gcov) from 2018-12 in our RCP, and switched the repository url to 2019-03, then check for updates proposed the gcov update.
At the end this seems to confirm my initial thought which is acceptable, check for updates only relies on what is shown in “Installed Software” tab.
In RCP by default, and with installMode=root, only features declared from .product figure in scope of check for update.
Then if any feature is manually installed, it will also be taken into account by the check for update.
I in no way suggested that Julien should do this; I expect that he doesn't. The point is that there are many way to specify requirements and I know the EPP packages have changed how it does this over time. So the underlying point is that even if he locks in specific versions for direct dependencies the indirect dependencies may not have done and so could potentially be updated...
On 21.03.2019 11:42, Mickael Istria wrote:
Back to the top