On 10/18/10 10:35, Richard S. Hall wrote:
I would not recommend going down some sort of singletons path...this
sucks in general. Once you start throwing in composites (or
subsystems) then it becomes confusing to the point of meaninglessness.
If the framework were a true bundle and properly imported the API
packages it exported (since it can't assume to the sole provider of
these packages), then the runtime resolver would do the right thing.
However, if it only exports these packages (possibly because it
modifies them in some way), then that's the real issue.
For this reason, I would never suggest that anyone try to install the
Felix framework as a bundle, since it wasn't properly packaged to be a
bundle (i.e., the Felix framework JAR file should be in an OBR repo).
Sorry, that should say, "...(i.e., the Felix framework JAR file should
NOT be in an OBR repo)."
-> richard
On 10/17/10 15:43, Neil Bartlett wrote:
In Bndtools[1] I am using the OBR resolver from Felix (in a slightly
modified form) to resolve build-time repositories and run
configurations. I have come across a problem that perhaps somebody has
seen before and can provide advice about.
Suppose I have a run configuration that uses Felix as its framework,
but the user has selected the DS implementation from Equinox. I
therefore have the following three resources as inputs to the OBR
resolver:
org.apache.felix.framework
org.eclipse.equinox.ds
org.eclipse.equinox.util
The Equinox bundles have dependencies on packages that are usually
supplied by the core Equinox framework when running on Equinox... but
there is a bundle "org.eclipse.equinox.supplement" that can provide
those packages in scenarios such as the above.
Unfortunately, the resolver picks "org.eclipse.osgi" to satisy the
dependency, meaning I would end up with the full Equinox framework,
running as a bundle inside Felix. This is undesirable.
I feel that a clean solution for this problem would be some kind of
"unique" capability. I do not want two OSGi Framework instances...
perhaps both Felix and Equinox could provide a capability (e.g.
"osgiframework") that was defined as unique, i.e. the resolver would
allow only one resource providing that capability. This would force
the resolver to pick org.eclipse.equinox.supplement, since Felix is
already selected.
Another desirable feature would be to constrain certain bundles
according to a profile. For example, in the above scenario the
resolver offers "osgi.core" (i.e. the OSGi core APIs) as an optional
resource. But osgi.core is special: I always want to use it at build
time -- in preference to either org.apache.felix.framework or
org.eclipse.osgi -- but I NEVER want to include it at runtime.
Any suggestions before I start to hack the above solution?
Regards,
Neil
[1] http://njbartlett.name/bndtools.html
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
