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


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