|Re: [cross-project-issues-dev] Orbit and WTP are not greedy, how about you?
1. Yes, using the PDE build/publisher as we do in Orbit and WTP, just changing to the Juno version suffices (I used Juno M4 Eclipse SDK), no other change or properties required. 2. I don't think this is a case where "forced qualifier" is needed. The artifacts do indeed have identical content, so ok that version/qualifier is the same. It is only a change to the content.jar/xml file metadata, and that will effect installs, not runtime behavior. If someone already has an Indigo version installed then "the damage has been done" already (that is, they already have the extra, unneeded stuff installed) so updating the version/qualifier of a bundle won't change that. I could be wrong on this, and others analysis is welcome. But, I suspect, any case that involved requiring the version/qualifier to change would be more complicated than simply "building and using Juno" so should probably deserve special discussion. For example, if someone tries to use the Juno repository and the Indigo repository at the same time, then they might prefer new versions/qualifiers, but as far as I know, using repos from multiple releases is not supported (not planned for, not tested, ... and, shouldn't be needed, as far as I know). HTH From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, Date: 01/23/2012 04:56 AM Subject: Re: [cross-project-issues-dev] Orbit and WTP are not greedy, how about you? Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx 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  and the p2 Publisher wiki  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,  https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099  http://wiki.eclipse.org/Equinox/p2/Publisher  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 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Back to the top