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. 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.
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
