Skip to content
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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

HannesWell
Copy link
Member

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 inside EquinoxCommandProvider.
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.

Copy link
Contributor

@tjwatson tjwatson left a 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() {
Copy link
Contributor

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) {
Copy link
Contributor

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) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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) ...

@laeubi
Copy link
Member

laeubi commented Apr 30, 2024

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?

@tjwatson
Copy link
Contributor

tjwatson commented Apr 30, 2024

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".

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.

@HannesWell
Copy link
Member Author

Sorry, I neglected this PR but agree that it is still relevant.
I'll look into the comments and will see if I can come up with a smaller set to start.
In general some utilities would probably be also helpful for PDE in order to migrate off the equinox-resolver API. But what would be helpful exactly will only become visible when going down that path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants