Skip to main content

[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

Back to the top