Home » Eclipse Projects » Equinox » Bridging Equinox To A Legacy Build System(Bridging Equinox to a legacy build system using programmatic bundle creation and loading.)
Bridging Equinox To A Legacy Build System [message #1744532] |
Tue, 27 September 2016 21:37 |
Rob Hatcherson Messages: 33 Registered: July 2009 Location: Fort Worth, TX, USA |
Member |
|
|
Eclipse Neon 4.6.0
JDK 8u92
Here at our site we're married to a legacy prerequisite resolution and build system, and we aren't going to escape from it any time soon. We use Eclipse for development, and would like to start using RCP for our presentation layer. So... I'm hunting for a way to bridge our established prerequisite resolution and build system and associated build products to OSGi/Equinox.
Our code base consists of several hundred individual projects that are managed by the aforementioned system. The build products of these projects are loosely analogous to OSGi bundles. A while back I participated in a forum discussion with Paul Webster where he suggested that we should be able to invent bundles on the fly for these projects, and introduce them to the framework by making programmatic calls to install(), start(), etc.
At the time I discussed this with Paul I had already managed to get something similar working for deployment purposes using classloading hooks. But... this approach felt like it was swimming upstream, and it didn't help with stuff like e4 tooling that wanted to use URL mechanisms such as platform:/plugin/... and bundleclass://... It seemed like a better option would be to coax the framework into loading our existing build products as if they were official bundles, and everything else would just work for both dev and deployment with no hook trickery required.
Having been inspired by the discussion with Paul I dug into the existing prerequisite resolution system and decided that enough info was there to generate .../META-INF/MANIFEST.MF files for each built project in our system to specify BSNs, classpaths, prerequisite requirements, etc. So... I made some changes to do that, and this looked like it made our build products into something that might be loadable as bundles.
Then I tweaked our local dev support Eclipse plugin to make it hunt down these projects and attempt to start them as bundles to introduce them to the already running framework. On the surface this seemed to work until I got to a project that declared a prerequisite on another project. At that point I got a squawk that there was an unresolved requirement.
A specific case:
Among the many projects/bundles are one whose BSN is zedasoft.java.scm, and another one whose BSN is zedasoft.java.foundation. zedasoft.java.foundation has a Require-Bundle header for zedasoft.java.scm (I know Import-Package is preferred over Require-Bundle, but Require-Bundle seemed like it should be the more painless thing to get working initially).
When I start zedasoft.java.scm the system goes through the motions and its state changes to ACTIVE.
However...
When I start zedasoft.java.foundation its state changes to INSTALLED, and it complains about not being able to resolve zedasoft.java.scm even though the system says zedasoft.java.scm's state is ACTIVE.
I flipped on the OSGi resolver debugging stuff and got this output for zedasoft.java.scm:
Resolver: resolving 1 in batch.
Resolving root bundle: osgi.identity; osgi.identity="zedasoft.java.scm"; type="osgi.bundle"; version:Version="3.23.0"
RESOLVER: Finding capabilities for requirement
osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.7))"
of resource
osgi.identity; osgi.identity="zedasoft.java.scm"; type="osgi.bundle"; version:Version="3.23.0"
RESOLVER: Capabilities being returned to the resolver
[1] osgi.ee; osgi.ee="JavaSE"; version:List<Version>="1.0.0,1.1.0,1.2.0,1.3.0,1.4.0,1.5.0,1.6.0,1.7.0,1.8.0"
of resource
osgi.identity; type="osgi.bundle"; version:Version="3.11.0.v20160603-1336"; osgi.identity="org.eclipse.osgi"; singleton:="true"
RESOLVER: Capability filtered because it was not effective
equinox.module.data; classpath:List<String>="lib/zsscm.jar,./classes,."; effective:="information"
of resource
osgi.identity; osgi.identity="zedasoft.java.scm"; type="osgi.bundle"; version:Version="3.23.0"
Resolver: resolved 1 bundles.
Resolved bundle: osgi.identity; osgi.identity="zedasoft.java.scm"; type="osgi.bundle"; version:Version="3.23.0"
Resolver: resolve batch size: 2147483647
Resolver: time to resolve: 52ms
Resolver: max used memory: 0Mo
Resolver: resolve batch size: 2147483647
Resolver: time to resolve: 0ms
Resolver: max used memory: 0Mo
RESOLVER: Wirings for resolved bundles:
Resource
osgi.identity; osgi.identity="zedasoft.java.scm"; type="osgi.bundle"; version:Version="3.23.0"
Wiring
[1] osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.7))" -> [osgi.identity; type="osgi.bundle"; version:Version="3.11.0.v20160603-1336"; osgi.identity="org.eclipse.osgi"; singleton:="true"]
RESOLVER: Capability filtered because it was not effective
equinox.module.data; classpath:List<String>="lib/zsscm.jar,./classes,."; effective:="information"
of resource
osgi.identity; osgi.identity="zedasoft.java.scm"; type="osgi.bundle"; version:Version="3.23.0"
...and I get this output for zedasoft.java.foundation:
Resolver: resolving 1 in batch.
Resolving root bundle: osgi.identity; osgi.identity="zedasoft.java.foundation"; type="osgi.bundle"; version:Version="5.118.0"
RESOLVER: Finding capabilities for requirement
osgi.wiring.bundle; filter:="(&(osgi.wiring.bundle=zedasoft.java.scm)(visibility=private)(resolution=mandatory))"
of resource
osgi.identity; osgi.identity="zedasoft.java.foundation"; type="osgi.bundle"; version:Version="5.118.0"
RESOLVER: Capabilities being returned to the resolver
RESOLVER: Wirings for resolved bundles:
org.osgi.service.resolver.ResolutionException: Unable to resolve osgi.identity; osgi.identity="zedasoft.java.foundation"; type="osgi.bundle"; version:Version="5.118.0": missing requirement osgi.wiring.bundle; filter:="(&(osgi.wiring.bundle=zedasoft.java.scm)(visibility=private)(resolution=mandatory))"
at org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:140)
at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolveRevisions(ModuleResolver.java:1062)
at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolveRevisionsInBatch(ModuleResolver.java:1020)
at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:938)
at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:131)
at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:485)
at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:443)
at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:433)
at org.eclipse.osgi.container.Module.start(Module.java:427)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383)
at com.zedasoft.eclipse.dev.plugins.utils.ScmOsgiBridgeBundleManager.startBundleFor(ScmOsgiBridgeBundleManager.java:320)
at com.zedasoft.eclipse.dev.plugins.dialogs.ScmOsgiBridgeBundleManagerDialog$BundleWorkspaceJob._runInWorkspace(ScmOsgiBridgeBundleManagerDialog.java:287)
at com.zedasoft.eclipse.dev.plugins.dialogs.ScmOsgiBridgeBundleManagerDialog$BundleWorkspaceJob.runInWorkspace(ScmOsgiBridgeBundleManagerDialog.java:174)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
RESOLVER: Resolution report
zedasoft.java.foundation [947]
Unresolved requirement: Require-Bundle: zedasoft.java.scm; visibility="private"; resolution="mandatory"
So the question is... why is the system failing to resolve zedasoft.java.scm when zedasoft.java.scm's status is ACTIVE?
Being a relative OSGi noob I'm not sure about what the spew above is telling me. For example, some of the stuff that looks scary may in fact be harmless and vice versa. I spent a while rooting around in the code orbiting that stack trace, but so far no revelations.
One possible clue: in the spew for zedasoft.java.scm it says:
RESOLVER: Capability filtered because it was not effective
equinox.module.data; classpath:List<String>="lib/zsscm.jar,./classes,."; effective:="information"
Does this effectively mean that this bundle isn't going to be able to resolve any future dependencies on it because it's effectively been filtered away?
The 'effective:="information"' didn't look too good either.
The OSGi console also says some stuff that I wasn't sure how to interpret:
osgi> b zedasoft.java.scm
zedasoft.java.scm_3.23.0 [957]
Id=957, Status=ACTIVE Data Root=/opt/eclipse-neon/configuration/org.eclipse.osgi/957/data
"No registered services."
No services in use.
Exported packages
com.zedasoft.scm; version="0.0.0"[exported]
No imported packages
No fragment bundles
No required bundles
osgi> p zedasoft.java.scm
No exported packages
So one command says there are exported packages, and another command says there aren't any.
I feel like this approach is just one or two noob mistakes away from working, and I'll have something that will allow our legacy goo to work and play well with Equinox.
Any guidance regarding what might be wrong?
Rob
|
|
| |
Goto Forum:
Current Time: Wed Oct 09 18:54:38 GMT 2024
Powered by FUDForum. Page generated in 0.03467 seconds
|