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.*
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
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
Hi Ed,
On Thu, Mar 21, 2019 at 11:36 AM Ed Merks 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
Hi Julien,
It seems like it's something you already understand enough to set up an
experiment and see by yourself ;)
Marketplace is not related, what you want to clarify is
1. Whether added p2 repo affect the Check for Updates behavior (I believe
answer is yes, ie if your extra repo adds new
Hi all,
I'm working on an Eclipse RCP with update process enabled; check for update
works like a charm, relying on our product repository (internal company server).
Today we are asked to integrate the Marketplace feature. This is also already
working fine thenceforth we declare an Eclipse
