[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [pde-dev] Target Platform question
|
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
