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