-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace deprecated PackageAdmin service with Wiring-API #47
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cannot have static API like Wirings
. If we are going to have Equinox specific API for this I suggest we prototype API as an extension of FrameworkWiring
and allow the system bundle to be adapted to that. Perhaps an interface in org.eclipse.osgi.contaiiner
. Something like ModuleContainerWiring
, but instead of the actual bundle objects it should return ModuleRevision
objects. Anything we do here we should be open to standardizing as new methods directly on FrameworkWiring
. Perhaps open an issue with the working group first with the use cases for some convenience methods on FrameworkWiring
? Or perhaps add some suggestions to osgi/osgi#425 where I was wanting to add APIs to OSGi R9 Core.
|
||
private static volatile BundleContext context; | ||
|
||
public static Bundle getSystemBundle() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cannot have statics like this in the framework. The framework from a single class loader can have many instances created. Each instance of the framework will have distinct system bundles and therefore distinct bundle contexts.
|
||
// TODO: check usage | ||
|
||
public static Stream<Bundle> getBundles(String symbolicName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cannot have static API like this to get the Bundle objects because multiple instances of the framework can be loaded from the same class loader.
|
||
// TODO: check usage | ||
|
||
public static Stream<Bundle> getBundles(String symbolicName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public static Stream<Bundle> getBundles(String symbolicName) { | |
public static Stream<Bundle> getBundles(BundleContext context, String symbolicName) { |
I would suggest to simply force users passing a BundleContext, given that one has to fetch the PackageAdmin
before anyways there must be a bundlecontext somewhere around, and the BC can be queried for the systembundle like BundleContext.getBundle(Constants.SYSTEM_BUNDLE) ...
I really like the idea of having some "WiringHelper" standardized, bnd also contains such helpers already and some common task are a bit tendentious to write "by hand". @HannesWell as this has many conflicts now, maybe it would be worth to just replace one single (hopefully trivial) case where it can be discussed where to place such things and then do it incrementally? |
I think we should do that in osgi/osgi#425 like I suggested in my review comment. In the mean time I think we can extend FrameworkWiring to experiment with something we would like to eventually spec. |
Sorry, I neglected this PR but agree that it is still relevant. |
Work in progress of the replacement of the deprecated PackageAdmin service within equinox.
The main work that is missing is the replacement of the
ExportPackages
insideEquinoxCommandProvider
.This requires some more code and I suspect that in the end a significant part of the PackageAdminImpl implementation as to be copied.
However I would like to discuss if the general direction is fine.