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. Regards, Julien From: p2-dev-boun...@eclipse.org [mailto:p2-dev-boun...@eclipse.org] On Behalf Of Ed Merks Sent: jeudi 21 mars 2019 12:01 To: p2-dev@eclipse.org Subject: Re: [p2-dev] RCP check-for-update standard behavior Mickael, 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... Regards, Ed On 21.03.2019 11:42, Mickael Istria wrote: Hi Ed, On Thu, Mar 21, 2019 at 11:36 AM Ed Merks <ed.me...@gmail.com<mailto:ed.me...@gmail.com>> wrote: But generally the p2 metadata produced for a feature.xml will lock in very specific versions of their included bundles and features which prevents those from being updated to a different version. That's sometimes annoying and then folks will use p2.inf information to specify looser requirements. E.g., the platform uses EMF but in an installation of some Eclipse package/product the users want to be able to update/install a newer version of EMF. I don't think using p2.inf is the more straightforward and sustainable (in term of maintenance) approach for that case. A feature can define dependencies with the <import> element to add a non-version-locked dependency that will be installed together with the feature. This is better supported by PDE and Tycho than a p2.inf and keeps everything in the feature.xml (easier maintenance). -- Mickael Istria Eclipse IDE<https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers<https://developers.redhat.com/> _______________________________________________ p2-dev mailing list p2-dev@eclipse.org<mailto:p2-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list p2-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/p2-dev
