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