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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/p2-dev
