[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [pde-dev] Target Platform question
|
On 05/28/2010 10:50 PM, Jeff McAffer wrote:
In short, our installs will not be reproduceable.
This is often already the case. Several features rely on requirements
that are never introduced as an include by a feature. And that's a good
thing because an increasing number of bundles are general purpose
things, not intended to be packaged separately.
In a typical install, there will be a common base that is introduced by
feature requirements alone. That common base will be floating in terms
of versions. The ability to handle that and make it work shows the power
of both p2 and the OSGi runtime.
I would like to take this one step further. Consider three types of
requirements:
1. Things included in a feature. When you install, those things will be
installed too.
2. Things required by a feature. Same thing here. When you install,
those things will be installed too.
3. Things that are required that you don't want to install. I.e.
non-greedy stuff. p2 must fail if it's not already installed.
The difference between greedy and non-greedy is much more significant
then the difference between #1 and #2. Non greedy really means
"required". If it's not there, please fail (speaking of legacy, I think
that was true for the old UM as well).
In my view, #1 and #2 are the same. And semantically, p2 has that view too.
Wether or not to use a strict range is up to the publisher. If he
explicitly states that ranges are allowed in the group that he creates
(like we do), then he does that because he want to avoid conflicts with
other groups that includes the same material. If he really wants to
describe something that is "reproduceable", then he can do that too. He
has a freedom of choice.
I'm hoping I'm missing something as this seems like a pretty bad problem. It basically means that we can never operate reliably in an environment were there are multiple versions in a repo.
I guess we have a different view on that. I'm using OSGi and p2 to be
able to manage this type of complex scenarios and operate safely within
them. I'm much more inclined to trust that an automated SAT driven
process will do the right thing than to trust a rigid, and thereby
fragile, combination of hand crafted set of features.
- thomas
