|
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,
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).
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/p2-dev
|
