Bugzilla – Full Text Bug Listing
| Summary: | [publisher] Plugin start configuration support in feature parser | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Katya Stoycheva <katya.stoycheva> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | krzysztof.daniel, pascal, t-oberlies, tobias.hammerschmidt | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=364246 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 263087 | ||||||
| Bug Blocks: | 364246 | ||||||
| Attachments: |
|
||||||
|
Description
Katya Stoycheva
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. |