Re: [pde-dev] Target Platform question

[Thomas Hallgren <thomas@xxxxxxx>]

On 05/31/2010 12:11 AM, David M Williams wrote:

The current "versioning rules"
http://wiki.eclipse.org/Version_Numbering
imply a pretty strict relationship between contents of a feature (or bundle)
and its version; if contents change, version should change.

Is this topic that is being discussed related to that?

Do these versioning rules need to updated or expanded as this issue
is worked out in Indigo?

IMO, those rules reflect the old conventions and need to be updated in Indigo.

In general, I think the notion of "includes" versus "requires" must be discussed in depth. p2 doesn't make this distinction and IMHO, there are good reasons not to. It does however make a distinction between greedy and non-greedy but that important facet of the difference between the feature "includes" and "requires" isn't captured by the PDE publisher.

Perhaps we need to add a third attribute to the requirement but personally, I doubt it. Instead, we should move away from the current "include/require" notion and instead talk about just requirements and whether they are greedy or not. The recommendation could then be to use explicit version ranges for content that you provide and looser version ranges for content that you share with others. You still "include" all of them. They are published on your site and they are expected to be installed when the feature is installed.

Non-greedy requirements (what I would like to see the feature "requires" translated into) are things that your feature needs but p2 should refrain from installing. One such requirement could be that some plug-ins are present to provide a well defined API. There might be several choices (some perhaps not EPL'ed) and it would be inappropriate for p2 to automatically make a decision on what to use. Instead, the user must either have one already installed or make a selection together with the feature when installing.

No matter what we name things, the use of ranges (already) leads to the "installs will not be reproducable" scenario that Jeff dreads. How do we manage that? Do we need to do something beyond what's already there?

Once we've reached an agreement on the above, then I think we must make some changes to what choices the user has when provisioning a target platform. I would very much like to have a platform independent and fully recursive provisioning that uses the slicer.

- thomas