Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Rob Hatcherson is currently offline Rob HatchersonFriend
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
Re: Bridging Equinox To A Legacy Build System [message #1744596 is a reply to message #1744532] Wed, 28 September 2016 17:54 Go to previous message
Rob Hatcherson is currently offline Rob HatchersonFriend
Messages: 33
Registered: July 2009
Location: Fort Worth, TX, USA
Member
After continuing to beat on this some this morning the problem appears to have been a malformed directive in the generated MANIFEST.MF file. The manifest generator that translated our legacy build system goo to OSGi-ese was including explicit directives in the Require-Bundle header for visibility and resolution, even though it was setting them to the default values of "private" and "mandatory" respectively. Unfortunately it emitted "=" instead of ":=" in the directives, and this caused the resolver to fail when the bundle attempted to start.

I disabled the code that was adding these default directives, and everything seems to resolve correctly now.

Now I move on to more practical matters, to see if this approach will allow me to eliminate the classloading hook approach altogether while also allowing stuff like e4 tooling to work. The approach is showing some promise, and if it all pans out it will be a good stop-gap to allow our existing system to cooperate interact with RCP until we can do something more committal.
Previous Topic:ClassNotFoundException: java.sql.* when running Eclipse IDE on Java 9 Early Access
Next Topic:Thousands of exceptions during boot, yet application is running - harmless or should be addressed?
Goto Forum:
  


Current Time: Thu Mar 28 13:44:47 GMT 2024

Powered by FUDForum. Page generated in 0.04986 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top