Is there much interest in the osgi application
service? It seemed interesting at the time it was spec'ed and it
fit OK into the Eclipse application story (but not perfectly). Since
then the specification has had no updates and I am not really aware of
it being used much outside of the Eclipse platform. That being said,
we can certainly take contributions to the implementation.
I would not separate out the org.osgi.service.application
package from the implementation. Instead I would make it a substitutable
export (import and export the package) so that if there is another exporter
of the package then it can get wired to that.
We can easily get rid of the PackageAdmin
usage and instead use the R5 FrameworkWiring API.
We may be able to separate out the usage
of the registry into a separate bundle, but it has been a long time since
I have touched this code so I don't recall how entangled all that registry
code is into the implementation.
Scott Lewis <slewis@xxxxxxxxxxxxx> To:
mailing list <equinox-dev@xxxxxxxxxxx> Date:
02/03/2016 01:31 PM Subject:
osgi application service Sent by:
Equinox implements the osgi application service (org.osgi.service.application) via this bundle:
This bundle has compile-time dependencies on both the equinox service registry (org.eclipse.equinox.registry), and PackageAdmin which for some
environments are a disadvantage. The org.osgi.service.application
package is also present in the same bundle as the implementation, which
is a debatable choice.
Would there be any appetite to refactor the org.eclipse.equinox.app bundle (perhaps into multiple dependent bundles) so as to:
1) Separate the impl of org.osgi.service.application from the parts that
are dependent upon the equinox service registry (so as to allow use of
the application service without the service registry) 2) Remove deps to PackageAdmin service 3) Possibly separating the org.osgi.service.application classes from the