On Apr 8, 2009, at 2:22 AM, Richard S. Hall wrote:
Perhaps I misunderstood your question, but I thought you were simply
asking for a way to explicitly specify from which bundles your
imported packages come. If that is all you want to do, then simple
import them using the desired bundle symbolic name and version
range, e.g.:
Import-Package: org.foo.bar; bundle-symbolic-
name="my.desired.bundle"; bundle-version="[1.0.0,1.1.0)"
These bundle attributes are added implicitly to every exported
package for the exporting bundle.
Of course, I agree with what Stuart says below, if you are going to
do this, you are defeating the whole purpose. You might as well
stick with Require-Bundle.
My conclusion at this point is.... if I want to use osgi without
require-bundle (or the above more complicated equivalent) I have to
make sure, through some non-standard mechanism, that only the bundles
I will accept are accessible to the osgi runtime. There's a little
bit of support in OBR in that I can write my own resolver, but there
are no well known useful strategies.
Is this correct?
thanks
david jencks
-> richard
On 4/7/09 12:43 AM, Stuart McCulloch wrote:
2009/4/7 David Jencks<david_jen...@yahoo.com>
Thanks for the response.... could you clarify a couple things
inline?
On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
Well, there is OBR which allows you to resolve a given bundle
together
with the transitive closure over its dependencies based on import
and
export packages
(
http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
).
You can tell the maven bundle plugin to generate an obr
repository for
you (
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
or use bindex from the OSGi in case you want to create a repository
for a set of bundles (http://www.osgi.org/Repository/BIndex).
IIUC a particular OBR repository file is a list of a set of
bundles with
some additional info. There is no requirement that the bundles be
related
in any way or that there is any kind of transitive closure.
The bundle plugin makes it look like the normal relationship
between an OBR
repo file and a maven repo is a single OBR repo file describing
everything
in the repo. So, assuming we had one of these OBR repo files for my
hypothetical worldwide maven repo, it would do us no good, as
would include
all the bundles that happen to provide some required imports.
but this is the point about the import/export approach - you
shouldn't mind
who provides
the imported package(s), as long as they meet the constraints
specified by
your bundle.
so in an OBR repository it may well be several bundles can provide
the same
package,
in that case it's up to your OBR resolver to decide which bundle to
pull in
- this might be
simplistic (ie. take the first match, like in the Felix
bundlerepository) or
more complicated
(ie. prefer Apache bundles, or small bundles) - the point is that
the OBR
metadata has
all the right information to allow you to decide how to
pick'n'choose,
without depending
on a specific named artifact
to see how useful this is, consider extending your application -
this might
introduce a new
constraint that conflicts with one of your original "preferred"
bundles, and
it might be that
another bundle in the OBR can satisfy both your original and updated
constraints, so this
new bundle gets pulled in and the old one swapped out - this would
not be
possible with
named dependencies
(FYI, P2 can also do this and there is an ongoing process to
standardize
both approaches)
On the other hand it would be theoretically possible to come up
with an OBR
repo file that only had one bundle for each import and then there
would be
no more ambiguity. On the other hand this is not automatically
extensible:
since a new artifact doesn't come with its own preferred
dependencies, any
time you add a new artifact you need to update the OBR repo file
to mention
it and any new dependencies it might require.
However, it looks like it would also be possible to turn each
maven pom
into an obr repo file and store it next to the maven artifact.
Starting
with one particular bundle you could look at its repo file, find
the repo
files for each bundle mentioned therein, and come up with the
transitive
closure. This seems like the same process maven uses for transitive
dependencies. As with maven, it's extensible. Since there are a
lot of
unrelated trees glued together it would be pretty easy to come up
with 2
bundles specified as providing the same package. However it would
be pretty
easy to use something like a "prefer closer to root" policy to
resolve these
conflicts and provide a way to override or correct ancestor's
choices.
this would effectively be the same as Require-Bundle, and just as
fragile
imho
if you wanted a "prefer closer to root" policy then that would
probably be
possible
with a single OBR file, you'd just have to find a way to encode that
information in
the additional metadata included alongside each bundle entry (OBR is
extensible
and can support additional capabilities/details)
Is this reasonably accurate?
many thanks
david jencks
In your alternate reality you could turn your maven repos in one
big
federated OSGi repository and then point the obr bundle to it to
discover and deploy bundles (the obr bundle comes with the default
felix zip - try the obr command in the felix shell).
Furthermore, we are just proposing a new project to the incubator
which is targeting provisioning:
http://wiki.apache.org/incubator/AceProposal (just in case your
interested).
Finally, there is a provisioning solution from eclipse as well.
Called
p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
regards,
Karl
On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<david_jen...@yahoo.com
>
wrote:
Lets suppose we were in an alternate reality in which every
artifact in
maven repos was a correctly configured osgi bundle, using
imports and
exports rather than require-bundle.
Now suppose I've downloaded all the bundles locally and have
fired up
osgi
so it can see all of them.
Now I try to load a bundle that imports some classes that are
available
from
several bundles, say the geronimo, sun, and tomcat servlet 2.5
spec jars,
or
perhaps the slf4j interface classes.
What facilities does osgi or felix provide to help decide which
bundle
will
be selected to provide these classes?
-background--
We're looking at using osgi in Geronimo. Currently we have a
classloading
system with most of the capabilities of the osgi classloading
model but
oriented more towards maven metadata. Each geronimo specific
artifact
has
some dependency metadata like maven dependencies that specify
most of the
classloader, and you can tweak it with filters to emulate the
import/export
conditions in osgi.
Since the (multiple parents) of an artifact are specified as other
artifacts, its easy, starting with a particular artifact, to
pull in all
its
dependencies by artifact name and obtain all the pieces that are
needed
to
run the artifact you are interested in. This is just like
maven: you
specify a dependency in your pom and it and all its transitive
dependencies
are automatically downloaded and made available to your build.
Btoh Geronimo and Maven have ways to override the original
dependencies
of
an artifact and substitute something else.
IIUC in osgi one can use require-bundle to specify dependencies
in a
similar
way but again IIUC this is highly frowned upon from a theoretical
perspective and I don't know of any way of overriding require-
bundle
specifications.
So.... is there anything in osgi or felix that provides this
kind of
dependency specification that can be used with import/exports to
specify
specific bundles to satisfy import requirements?
many thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Karl Pauls
karlpa...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
