Open laeubi opened 1 year ago
Looking at https://docs.osgi.org/specification/osgi.core/8.0.0/framework.lifecycle.html#i1236436 I also can't find an indication that the data there is considered only a cache ("private persistent storage area").
The bundle data area lives with the installation of a bundle. When a bundle is no longer installed then its bundle data area must also be removed. When using -clean
all bundles effectively are no longer installed. This is the same when you use the framework launch option https://docs.osgi.org/javadoc/osgi.core/8.0.0/org/osgi/framework/Constants.html#FRAMEWORK_STORAGE_CLEAN_ONFIRSTINIT
Given that P2 / SimpleInstaller sometimes mess up things and we recommend to call clean it seems there might then be an option required to flush cached state but retain the bundle data (e.g. by only clear items that are really uninstalled, e.g. bundle location has changed or version or symbolic name) and better document that this not really clears cached data (what one usually reads as "data that can be recovered from other sources") but wipes out even persistent data.
Given that P2 / SimpleInstaller sometimes mess up things and we recommend to call clean it seems there might then be an option required to flush cached state but retain the bundle data (e.g. by only clear items that are really uninstalled, e.g. bundle location has changed or version or symbolic name) and better document that this not really clears cached data (what one usually reads as "data that can be recovered from other sources") but wipes out even persistent data.
This will not be how other compliant frameworks behave and I think it would violate the specification. Bundle data is associated with an installed bundle which has a location + bundle ID (long) value associated with it. When doing -clean we could have the same bundle locations, but the bundle ID may very likely change from the previous state we cleaned.
So osgi.clean
/ -clean
is effectively org.osgi.framework.storage.clean=onFirstInit
, I'm just asking because I can't find osgi.clean
in the spec, and at least the Eclipse doc seem to indicate a different purpose (cleaning cached data) that what org.osgi.framework.storage.clean
indocates (clearing the persistent storage area).
osgi.clean
is Equinox specific and predates the spec'ed onFirstInit
. If onFirstInit
is used we always end up setting osgi.clean
to true:
This is because other things in Eclipse pay attention to the osgi.clean
value, like the extension registry.
This issue has been inactive for 180 days and is therefore labeled as stale. If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below. Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.
This issue has been inactive for 180 days and is therefore labeled as stale. If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below. Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.
This issue has been inactive for 180 days and is therefore labeled as stale. If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below. Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.
On the help page it says:
In fact this does not really clear out only cached data but also the "persistent bundle area" a bundle get when calling
org.osgi.framework.BundleContext.getDataFile(String)
this is also where the configuration admin usually stores data, so also all user-configuration get wiped when using-clean
Currently this won't be noticed much as eclipse uses it own "preferences" that are stored in the workspace and Plugins are using
Platform.getStateLocation(bundle)
, but this is of course not an option for "pure" OSGi components that don't want to bind to Eclipse specific things.