Skip to main content

[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?

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).


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 ?


-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [
mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M
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

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

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

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

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,


cross-project-issues-dev mailing list
cross-project-issues-dev mailing list

Back to the top