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 > > -- Cheers, Stuart
