[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Orbit build qualifiers changing with each build
|
On 2011-02-02 09:24, Eike Stepper wrote:
Am 02.02.2011 09:05, schrieb Thomas Hallgren:
On 2011-02-02 08:47, Eike Stepper wrote:
, especially related to Buckminster
Can Buckminster please confirm that this is a Buckminster issue?
Nope.
That's what I thought. But who/what is it then?
Jeffs standpoint last year was that all includes must appoint explicit versions (hence the exact [x,x] version range in
the generated p2 requirements). If you don't want strict version requirements, then you are probably not the publisher
for the bundle that you include. The org.apache.derby bundle for instance, is not your creation. You should probably
'require' this bundle, not 'include' it. That however, has other bad side-effects in that it effectively breaks some PDE
target provisioning scenarios [1].
The semantics are indeed confusing. The terms 'includes' and 'requires' stem from the old update manager but have a
different meaning today [2]. Better terms and editors are needed in order to leverage the power of p2. IMO, there's a
lot of unnecessary pain involved in publishing and it's one of the things that newcomers to the wonderful world of OSGi
and p2 find very difficult to grasp.
So while it's true that Buckminster indeed does generate a strict version requirement for includes, this is per Jeff's
recommendation and it's also what PDE build does. It's not a Buckminster "issue". Buckminster is flexible and you can
control both the version generation and the greedy status using various options but the default is to mimic what PDE
build does.
HTH,
Thomas Hallgren
[1] The PDE target provisioner, unless you uncheck the "include required software", will tell the resolver to "only
include dependencies that have exact version requirements". It looks like some kind of workaround for the fact that at
that point, with only IU requirements to look at, there's no way of telling if the actual dependency is an 'include' or
a 'requires'. To add to the confusion, the check-box caption starts with the words "include required". Go figure ...
[2] In the old (pre p2) days, the 'requires' resulted in a non-greedy dependency. The installation would fail if the
requirement wasn't already installed in the target. Not so today. P2 will happily install a requirement just as it will
install something that you include. The only difference from a p2 perspective is that when you use requires, you can use
a version range. While p2 sure has the concept of greedyness, it's not used when generating features.
