Re: [pde-dev] Target Platform question

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

Hey Thomas, 

It would be great to have a new construct that allowed the authoring and capture of the additional power in p2. Right now however, people authoring features and infrastructure manipulating features expect feature semantics, old and outdated as they may be. Namely, in this case, that inclusion is of a precise version.  I don't think that it is fair game to change this to a range under the covers as it completely does not match the expectations of a feature author or consumer.

As for the behaviour of the target provisioning, sure, it would also be great to have better support there.  The PDE team has been making considerable strides on this though some of that work will not make it into Helios. This is, however, not just a target thing.  

If you install, into your IDE or app, version X of a feature F that was built with and includes version Y of bundle B, the expectation is that you get B.Y installed. If the IU for F was morphed such that its <require> on B was changed to a range, then installing F.X will get you any B that fits in the range and happens to be available in a repo known to the p2 agent at the time.  Do it again at a different time and you get a different result.

That behaviour can be useful but it is not at all what was expected by the feature author or indeed the feature consumer. Folks that wanted a range should have used requirements in their feature not includes. Again, it would be great to have a new thing to breath life into features but it seems a problem to simply change under the covers the semantics that have been around for 10 years.

For context, do you know of many projects other than the EMF folks who are using this approach of mapping inclusions to version ranges?

Jeff

On 2010-05-28, at 10:41 AM, Thomas Hallgren wrote:

> Hi Jeff,
> Whether or not the use of version ranges in a grouping IU is a "semantic bug" or not can be debated. There are no semantics in p2 that describes "includes" versus "requires". Conceptually, the greedy flag is close, but for some reason it's not used.
> 
> We exploit the p2 grouping concept to its full extent using ranges. Obviously that doesn't play well with the assumptions and guesses made by the target platform provisioner but I don't think what we do is buggy. Pushing it, I would instead claim that the target platform provisioner in its current shape is flawed and that the assumptions made are based on old conventions that are now abandoned by many since p2 is far more powerful then the old UM.
> 
> - thomas
> 
> 
> On 05/28/2010 03:59 PM, Jeff McAffer wrote:
>> This arises from usecases where the target platform does not need to be "runnable" or consistent in any way. For example, the "Target Component" features that are provided in the Target Platform Components category of the Helios repo are not intended to be consistent or runnable.  They may include overlapping and even conflicting bundles. They may also include a very wide range of functionality only some of which would be useful to any particular product/scenario. Following all dependencies would pull in too much (e.g., add the whole IDE when doing RCP development).
>> 
>> Following this workflow should be the logical equivalent to getting the feature zip and adding it to the target. No more. No less. Feature zips coming out of the build contain only the elements that were *included* (transitively) in the feature. One characteristic of inclusion is the fact that precise version numbers are used.  That is, version X of feature F is exactly the *specific* things that it includes. It may happen to require some other things but those are not part of F. So in the absence of further information in the p2 metadata regarding what is included vs required, strict version ranges fit the bill.
>> 
>> In this scenario the only downside is that if someone happened to make a *requirement* in a feature and set the match rule to "perfect", those elements would be added to the target. I suspect that the use of perfect match is vanishingly small so this should not be a widespread issue.
>> 
>> I did see an issue the other day in the EMF SDK where the feature spec'd inclusion but part of their build was changing the expected precise version numbers to a wider range. This is a semantic bug in their build. When a developer says that F includes bundle B, the semantics are that it is a specific version of B.  That is why feature inclusion does not allow for ranges or match rules. We can certainly review features and look to have a new construct with different semantics but for now, the p2 metadata has to match the expected semantics expressed in the features.
>> 
>> Jeff
>> 
>> On 2010-05-27, at 3:50 PM, Thomas Hallgren wrote:
>> 
>>   
>>> Hi,
>>> 
>>> I was recently made aware that if I provision a target platform with "Include required software" unchecked, the slicer used will only follow consider requirements with strict version ranges. I fail to see the logic in that. Can someone please explain why that is?
>>> 
>>> Regards,
>>> Thomas Hallgren
>>> 
>>> _______________________________________________
>>> pde-dev mailing list
>>> pde-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/pde-dev
>>>     
>> _______________________________________________
>> pde-dev mailing list
>> pde-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/pde-dev
>>   
> 
> _______________________________________________
> pde-dev mailing list
> pde-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pde-dev