Re: [pde-dev] Target Platform question

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

The short form here is that if you ship a Feature in the repo then the corresponding metadata should match what is in the Feature itself (i.e, in the feature.xml). *

Developers consuming Features in the creation of their products/launch configs/Features must be able to rely on the Feature information as matching what will actually happen at end user provisioning time. 

Similarly, end users consuming things from various repos also need a clear understanding of what they are getting. If you write, test, publish and distribute a product that says it uses EMF from June 2010 then when the product is installed, it seems likely that the June EMF bundles should be used. Not the ones from Sept 2010 (or some others) just because they happened to be available in some repo that the p2 agent could see at the time. At least not without some user engagement. Unfortunately today, we do not have the UI affordances to make the choices and impacts clear to users. Inconsistent semantics and incomplete workflows will undermine user trust in their installs and the platform in general. 

To be clear, it will be great when we have a full-fledged replacement for Features that have the characteristics and capabilities that you outline plus more. There are many use-cases that Features and p2 do and do not handle today. Moving forward on this will require broad community engagement and education, as the current state has broad community adoption and understanding.

To kick start that discussion, I posted a message pointing to this thread in the Architecture Council mailing list and on the Cross Project list. At this time it is unclear how many projects are using this technique.  Hopefully the broader interaction will shed some light on the Helios situation.

Jeff

* The semantics of Features are pretty clear. There has been some evolution in the mechanics around the metadata but, for example, p2 or UM never reinterprets a Feature's version ranges or values to be different than they are. Following transitive dependencies is not equivalent to broadening version ranges. As for p2.inf tweaks, the common use of p2.inf is to *add* to, not change, the data that is supplied by the feature.xml itself. While it is possible to hack a Feature using p2.inf that does not mean that people should.


On 2010-05-31, at 5:35 PM, Thomas Hallgren wrote:

> The "Feature Manifest Editor" chapter in the Eclipse Help PDE Guide has the following statement:
> 
> "The Dependencies page lists all Required Features and Plug-ins that must be present in the product before the Update Manager installs this feature. If any of these pre-requisites are missing, the feature will not be installed."
> 
> This was true for a very long time. Yet, today requirements are used (and recommended) as means to get things installed. How is that not a breaking API change? Is it perhaps because the feature was an old UM concept and not really used as such today?
> 
> Incidentally, the statement describes exactly the p2 non-greedy function.
> 
> I bring this up as an example showing how the current implementation deviates from what's "clearly said". I doubt anyone considers it a bug though. Another is that historically, a requirement has never been able to contain a filter (I know this was partly fixed very recently but there is still no tool support and no documentation).
> 
> To sum it up:
> - Someone with a long experience of Eclipse will not think about a feature requirement as a way to get something installed. Instead he will put the non-greedy meaning to it.
> - A newcomer will consult the documentation and try the feature editor and come to the exact same conclusion as the experienced user.
> 
> Due to the somewhat fuzzy interpretation of what a feature.xml really is in terms of p2 meta-data, we made a choice early on to use it as a template and then control the p2 group generation using properties. Consequently, we have a property that can control greedyness on requirements. We also have a property that control the ranges used for includes.
> 
> In the same vein, the p2.inf file was introduced to influence both features and bundles beyond what could be extracted from the manifest. I'm fairly convinced that the majority of p2.inf files out there modifies features in one way or another.
> 
> I think it's a modified truth to say that "most consumers" will use the binary features. I never do. I always use the p2 meta-data and I think that's what most consumers do too. Simply because that's what the UI presents to them. I've had many users ask me how to browse p2 meta-data but never have the feature.xml come up as a way to find information.
> 
> I can't find any reference that says that the p2 meta-data must be in sync with the feature.xml. I do find more then one article that describes how to use p2.inf file to introduce things that will ensure that they indeed will differ. None of the mentions breaking API changes.
> 
> All in all, it feels very much that we are in the middle of a transition from old legacy to a more modern implementation. During that period, I think there's a danger in putting too much weigh on how things always have been. There is no single truth anymore. That's what we need to adopt to.
> 
> - thomas
> 
> 
> 
> On 05/31/2010 08:02 PM, Jeff McAffer wrote:
>> On 2010-05-30, at 5:27 PM, Thomas Hallgren wrote:
>>   
>>> Given the current behavior of the target platform provisioning and the fact that its too late to change that now, I agree the default behavior should be to use a perfect match for feature includes. That's also what EMF SDK does now to avoid problems.
>>>     
>> Great.  To be clear though, this is not just target provisioning.  It is also IDE, RCP, Server, ...  install scenarios that are affected.  I strongly suggest that all projects follow the current practice for Helios. If you want ranges then use requires in your features.
>> 
>>   
>>> Regarding p2 metadata and feature mismatch, I don't see any problem. The feature is never used once the p2 meta-data has been generated. It acts as a template for the grouping IU and typically has no versions declared for its includes. They are always generated. This means that a) there is always a mismatch between the template and the generated IU, and b) the feature has no role to play beyond being used as a template. And then there's of course the p2.inf that can rewire the IU completely. Add that by just flipping a property, you can choose not to install the feature jars at all. So where is the problem really?
>>>     
>> You see the feature as a template but most consumers of never look at the p2 metadata so all they ever see is the feature.  They look at the feature and say "ok, XX is included" and then assume a precise version is identified and that that is what they will get. This has been true for 10 years and would be a breaking API change if it were not true in Helios.
>> 
>> There also seems to be an assumption that people look at features in source form. To do that you would have to check it out from CVS/SVN/...  I'm pretty sure that the majority of consumers look at the *built* features as delivered in their target or various zip files. These should have precise version numbers.  If they don't (e.g., if they still have 0.0.0) then it is a bug as the feature manifest spec clearly says that<plugin>  tags identify specific versions of plugins.
>> 
>> Again, there is no argument that p2 offers more flexibility and power etc. That's why we did it! A new construct should be defined to clearly express those new characteristics.  We have yet to do that.  The fact that one can use p2.inf or buckminster or ... does not mean that they should.  I would argue strongly against someone tweaking metadata in this way under the covers.
>> 
>> Jeff
>> 
>> _______________________________________________
>> 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