2009/4/9 David Jencks <david_jen...@yahoo.com> > > 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. >
well, if you already know what bundles you will accept then you can use the standard OSGi APIs for installing those bundles - or something like FileInstall which installs bundles from a directory. OBR in this sense is probably overkill, as one of the aims of OBR is to help resolve a consistent set of bundles from a potentially large space of possible permutations, based on a given criteria. BTW, given your maven example you might want to look at the Pax tools over at OPS4J you can use the maven-pax-plugin to provision bundles based on a Maven project: it traverses the Maven dependency graph looking for bundles and then uses Pax-Runner to deploy them 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 > > -- Cheers, Stuart
