Community
Participate
Working Groups
Build Identifier: Currently there is PDE UI for configuring plugin start flag only on product level. It would be useful to have such option on feature level as well Custom configuration of a feature containing ~30 bundles (like p2 feature) requires ~800 lines of p2.inf. The file length and its complexity (one should know p2 metadata representations) makes it too difficult for troubleshooting and maintenance. Current proposal is only for the start flag. Reproducible: Always
Created attachment 207281 [details] Feature parser now understands autostart flag
PDE UI bug linked. I think they don't depend on one another from technical perspective, just make an end-to-end scenario complete.
I agree that the authoring experience is rather bad. If I understand correctly, the proposed solution allows the user to flag the feature as "autostart" and I suppose set a start level that will be applied to every plugin. I have a few questions: - How many CUs are generated? What are they attached to? - What happens when two features include the same plugin with different start levels? - What happens when the plugin has a p2.inf and this functionality is used?
(In reply to comment #3) > I agree that the authoring experience is rather bad. > If I understand correctly, the proposed solution allows the user to flag the > feature as "autostart" and I suppose set a start level that will be applied to > every plugin. It's actually a start configuration per plugin, rather than a flag on a feature level. When the user selects a plugin to be included, he could decide to mark it as started (the default is false). Here's an example of a feature.xml: <feature id="TestF" label="TestF" version="1.0.0.qualifier"> <plugin id="Test" download-size="0" install-size="0" version="0.0.0" autostart="true"/> </feature> I think that starting all plugins of a feature would be a rare case. > I have a few questions: > - How many CUs are generated? What are they attached to? It's one CU per plugin (when autostart is set to true). All are attached to the feature. > - What happens when two features include the same plugin with different start > levels? Each feature decides whether the plugin would be started or not and corresponding CU is attached. The new attribute is more related to a plugin as FeatureEntry rather than to the plugin as standalone unit. Does it make sense? > - What happens when the plugin has a p2.inf and this functionality is used? I looked for a priority mechanism in ProductAction where the same ambiguity could appear but couldn't find any. Currently if there's a p2.inf defining a feature req to a generated CU then both would be attached and at runtime one would be picked randomly. What do you think should be the correct behavior? (Currenlty, as far as I've seen, from purely code point of view it's easier to ignore p2.inf if there's configuration of the new kind) We can discuss a priority mechanism (if it doesn't exist), just need to have in mind that it should be adopted by the product action in order to ensure consistent behavior.
(In reply to comment #4) > > - What happens when two features include the same plugin with different start > > levels? > Each feature decides whether the plugin would be started or not and > corresponding CU is attached. The new attribute is more related to a plugin > as FeatureEntry rather than to the plugin as standalone unit. Does it make > sense? So if both features are installed, there are two CUs for the same plug-in. AFAIK this is not supported - see bug 263087.
