| Summary: | How to invoke '-clean' automatically after update? | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Michael Spector <spektom> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | pascal, remy.suen, tjwatson |
| Version: | 3.5.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| Whiteboard: | |||
|
Description
Michael Spector
No, this is not possible. What you can do is install an IU that set the osgi.clean property to true. oops... validated to fast You can then uninstall this IU upon a successful restart. That said I think the fact that this plugin is not picked is highly suspicious (since the old one should no longer be in the bundles.info) and we would appreciate if you could open a bug with steps against equinox. (In reply to comment #2) > oops... validated to fast > You can then uninstall this IU upon a successful restart. > That said I think the fact that this plugin is not picked is highly suspicious > (since the old one should no longer be in the bundles.info) and we would > appreciate if you could open a bug with steps against equinox. How about this one? Regarding steps, it seems like the bug doesn't happen all the time, we've only seen this happening for some customers, which is really weird. There's nothing special in the setup, our RCP application is based on features. The "problematic" plug-in is a Mozilla XPCOM, which has a 4 digit version, like: 1.9.2.13_201101261729 Dependent plug-ins require this version strictly: org.mozilla.xpcom;bundle-version="1.9.2.13" What files should I attach to this bug in case this happens again? If the situation occurs again you would have to attach the state files in configuration/org.eclipse.osgi/ as well as the configuration/org.eclipse.equinox.simpleconfigurator/bundles.info and the problematic bundles. |