Community
Participate
Working Groups
Currently the only API that we have to model Features is in the Classic Update Manager code and that is deprecated as the UM bundles are intended to be removed eventually. Because of this, we have several "feature" objects in our p2 code... in the eclipse touchpoint, in the metadata generator, in the publisher, etc. Also because there is no real API, PDE also has feature objects that it creates and uses. I believe the original intention was to remove the concept of features but it appears that going forward they will be around, if for no other reason than they are a familiar concept to users and there is tooling for them. If this is the case, then the question is: should we create API for features (and other UM concepts) to remove duplication? We could create API for: features, configurations, sites, etc. It would be an interesting exercise to create a feature object which conforms to the IInstallableUnit API so they could be used inter-changably.
I think there are two questions here: 1) Should we have a common copy of the feature code in p2 rather than many (code for parsing/writing)? 2) Should we have public API for anyone to use? My initial take is that having 1) would be fine but don't like the idea of 2). Conceptually feature.xml isn't sufficiently expressive to be a full authoring mechanism for installable units. So, today we have a combination of feature.xml and p2.inf to properly capture all the semantics. If you only look at the feature.xml you are only seeing part of the picture and are likely to misinterpret the metadata. So, clients in the outside world should really be dealing directly with IInstallableUnit, etc, rather than trying to parse/write feature.xml files themselves. Internally, we need to be able to parse/write both feature.xml and p2.inf but don't need full public API in order to do that.
My answer to the question asked in the title (Need API for features) is a loud NO :) Features are dead, long live features. We use them as authoring mechanism because we don't have anything better. Unifying the parsing code of feature, sure, but nothing else. btw, talking of duplication we also have several copies of the product parser.
As an advocate for Buckminster, a tool that where one common tasks is to extract, and sometimes modify, what's in the feature.xml, I would very much like to see #2. I'm well aware that the feature.xml isn't the way forward but our tool also need to support older and current builds. At present, the feature.xml file is the public interface for most people since it's the only thing that you can author using the IDE. I can't see any harm in having a public API that makes it easy to deal with the file. It's not likely to go away for some time. I would not be surprised if other tools in the same domain would be equally pleased if there was a public feature API.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
