[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Orbit and WTP are not greedy, how about you?
|
Hi Dave,
Many thanks for this notice and all the background.
I'd like to have just few things clarified,
1. What triggered the change for Orbit and WTP was simply upgrading to a 3.8 or 4.2 based builder (and thus newer p2 publisher) no change in any settings. As a corollary, anybody who already uses a 3.8 or 4.2 based builder already performs builds using the new strategy. Correct ?
2. Since only upgrading the builder may affect build output of plugins which were not modified in source, it may be adviseable to force updating the qualifier for any plugins that have been completely unmodified since the Indigo releases and contain any optional dependencies ... or we'd have two artifacts with exactly the same ID but different binary content. Correct ?
I have no idea how Tycho based builds behave regarding optional dependencies, does anybody know how their p2 publisher works ?
Thanks
Martin
-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Saturday, January 21, 2012 3:14 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: [cross-project-issues-dev] Orbit and WTP are not greedy, how about you?
I wanted to give some advance warning that I have upgraded the Orbit and WTP build so it produces repositories where the run-time optional bundles are specified as non-greedy. This will take effect for M5, in particular, for Orbit, the for-M5 Orbit build of http://download.eclipse.org/tools/orbit/downloads/drops/S20120120232307/
See bug 247099 [1] and the p2 Publisher wiki [2] for some history and details on this issue of greedy vs. non-greedy requirements.
In short, p2 assumes greedy='true' if it is not specified and in the past the publisher did not specify it, so there have been many cases in the past where users and adopters get things installed that they did not want or need. Plus, it would depend on which repo was "pointed to" or what was available in that repo at the time of the install, making things a little indeterminate. Rather than change the way p2 works (which would have had compatibility issues) it was decided to change the way the p2 publisher works.
Most of the time, this change will be nothing but goodness, but I'm giving this notice since it does have the potential to "break" something ... or, at least, not work as expected.
Potentially it could effect builds, if you use p2 to fetch Orbit pre-reqs and if you really required some optional thing, but did not specify it explicitly, getting it "by accident" before, due to a bundle having it as an optional dependencies.
The more likely impact would be in distribution packages or user installs which might have the same issue, of wanting something they got before "by accident" but would not now be installed, unless explicitly specified in a feature.
The fix, if any required, in most cases will be to add some missing optional item to a feature; sometimes it would be an existing feature, but often might be a new feature, in order to let users or adopters decide if they want that optional thing or not.
If you do encounter an issue where this change effects your project, especially in a negative way, I would appreciate a note in bug 368999 so we understand unanticipated impacts.
How about your repo?
I mean this as a rhetorical question, for now, but encourage everyone to move to this type of repository for Juno (not for Indigo SR2) where "optional at runtime" is not "greedily installed". If we have a mix of some specifying them as greedy and some not, I suspect the resulting builds, package distributions, and common repository will be indeterminate when we aggregate. And indeterminate is bad. We'll discuss this more for M6 as we gain experience with M5.
Thanks everyone,
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099
[2] http://wiki.eclipse.org/Equinox/p2/Publisher
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=368999
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
