Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] RCP check-for-update standard behavior

Well… the 2nd test was done a bit too fast.


> 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.


Fact is that even if only gcov update is shown most of org.eclipse.* plugins are updated silently which is the worst thing for us.


I guess that there is no other solution than fixing versions on each of our dependencies… and crossing our fingers to hope that such dependent components well manage their own dependencies. Tycho may already have an option for that, will document myself :-)

Or maybe another one could uses the <includes> tag from top rcp feature.xml to refer each org.eclipse.* features we would like to restrict/fix.


Some more trials to proceed =)


From: Julien DEHAUDT
Sent: jeudi 21 mars 2019 13:57
To: p2-dev@xxxxxxxxxxx
Subject: 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.





From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
Sent: jeudi 21 mars 2019 12:01
To: p2-dev@xxxxxxxxxxx
Subject: Re: [p2-dev] RCP check-for-update standard behavior



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:

Hi Ed,


On Thu, Mar 21, 2019 at 11:36 AM Ed Merks <ed.merks@xxxxxxxxx> 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 developer, for Red Hat Developers


p2-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top