Peter, Ah, that makes perfect sense, and now seems pretty obvious once you pointed it out :). The method signature in the RFC threw me off: Resource getResource(java.lang.String respositoryId). Should be Resource getResource(java.lang.String resourceId).
Thanks! ken ----- Original Message ----- From: "Peter Kriens" <[EMAIL PROTECTED]> To: "Ken Gilmer" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], "OSGi Developer Mail List" <[email protected]> Sent: Tuesday, December 11, 2007 1:53:37 AM (GMT-0500) America/New_York Subject: Re[2]: [osgi-dev] RFC 112 Bundle Repository Questions I do not think there is another place. :-) There is an id attribute in the resource element ... This is a local unique id. I see the id in the OSGi OBR instance and in the code: public static Tag toXML(Resource resource, boolean relative ) { Tag meta = new Tag("resource"); URL url = resource.getURL(); String urlString = url.toExternalForm(); if ( relative ) urlString = makeRelative(resource.getRepository().getURL(), url); meta.addAttribute("uri", urlString ); meta.addAttribute(SYMBOLIC_NAME, resource.getSymbolicName()); if (resource.getPresentationName() != null) meta .addAttribute(PRESENTATION_NAME, resource .getPresentationName()); meta.addAttribute(VERSION, resource.getVersion().toString()); meta.addAttribute("id", resource.getId()); ^^^^^^^^^^^^^^^^^^^^^^ Is this not what you mean? Kind regards. Peter kriens KG> Christer, KG> Thanks for the help. I ended up using the bindex program KG> against our bundles as the standard. Which brings up another KG> question about RFC 112. On page 13: KG> "..A specific Resource object can be found with the getResource KG> method. This method takes the repository local id as parameter." KG> "local id" is only mentioned once in the spec, and it's in this KG> sentence. The XML generated by bindex does not contain an id KG> attribute for the repository tag. Is the local id the name? KG> Also, is this list the best place for this sort of question? KG> thanks! KG> ken KG> ----- Original Message ----- KG> From: "Christer Larsson" <[EMAIL PROTECTED]> KG> To: "OSGi Developer Mail List" <[email protected]> KG> Sent: Monday, December 10, 2007 11:46:28 AM (GMT-0500) America/New_York KG> Subject: RE: [osgi-dev] RFC 112 Bundle Repository Questions KG> Ken, KG> The KF repo that we link to from knopflerfish.org is indeed an KG> older version, almost ancient by now ;-) KG> There is also an RFC 112 compatible version available at: KG> http://www.knopflerfish.org/repo/bindex.xml KG> Quite well hidden I'm afraid... KG> This is this repo that is used by: KG> http://www2.osgi.org/Repository/HomePage KG> A move to RFC 112 as the default format on kf.org is on the ToDo. KG> Regards, KG> Christer KG> Makewave KG> http://www.makewave.com KG> -----Original Message----- KG> From: [EMAIL PROTECTED] KG> [mailto:[EMAIL PROTECTED] Behalf Of Ken Gilmer KG> Sent: den 6 december 2007 19:55 KG> To: OSGi Developer Mail List KG> Subject: Re: [osgi-dev] RFC 112 Bundle Repository Questions KG> Thanks for the clarifications Richard. KG> -ken KG> On Dec 6, 2007, at 12:30 PM, Richard S. Hall wrote: >> Ken Gilmer wrote: >>> Sorry, I'm still a little confused about the OBR >>> implementations. The kf repository seems to contain entirely an >>> different XML structure than what's in the RFC. Is this just a kf >>> specific implementation not related to RFC 112? >> >> KF was using an earlier version of OBR that I created for Oscar, >> the spec is an evolution of that earlier OBR that uses a generic >> capability/requirement model for describing imports, exports, etc. >> >>> Additionally, the Felix repository page contains this line: >>> >>> a detailed description of the OBR meta-data format is available in >>> the OSGi RFC 112 document; this document is *not completely in >>> sync* with the implementation, but the concepts are still correct. >>> >>> Which parts are out of sync? Should the current Felix >>> documentation trump the RFC 112 document where they differ? >> >> Off the top of my head, I don't remember where they differ since it >> has been a while since I implemented it. I would not say that the >> Felix impl trumps the RFC, I would say the issues still need to be >> ironed out. Unfortunately, you are probably going to have to accept >> that there is a little bit of a grey area here since the RFC is not >> a completed spec. Yes, in the future, some aspects may change, but >> I would expect it to change in consistent ways. >> >> -> richard >> >>> >>> Thanks Again :) >>> >>> ken >>> >>> >>> On Dec 5, 2007, at 3:11 PM, Richard S. Hall wrote: >>> >>>> Peter Kriens wrote: >>>>> The infancy is related to both the RFC 112 and even more to the >>>>> current implementation. There is no plan to finalize it at this >>>>> moment >>>>> in time. >>>>> >>>>> Personally, I think OBR is one of the biggest missing pieces in the >>>>> OSGi story. However, I am a one man company that has too many >>>>> different things on its plate :-( and I seem to be not capable of >>>>> getting the commercial companies interested to work on this or fund >>>>> work on this. I guess another tragedy of the commons case. We >>>>> all like >>>>> to have it, but nobody is willing to fund it. >>>>> >>>>> As far as I know there is nothing specific R3 in it, but you >>>>> will find >>>>> it out by trying :-) >>>>> >>>>> >>>> >>>> There will definitely be differences between an OBR for R3 and >>>> one for R4. Specifically, the OBR implementation at Apache Felix >>>> assumes that it can install and resolve multiple versions of the >>>> same package. This will not be possible on R3. Essentially, OBR >>>> for R3 will pretty much throw out most version handling since >>>> there can only ever be one. >>>> >>>> Granted, some of this stuff isn't specifically covered in the >>>> RFC, if I recall. >>>> >>>> -> richard >>>> >>>>> About licensing, there is currently in the OSGi een RFC >>>>> (implementation) about a Bundle-License header that should >>>>> address some >>>>> of your needs. >>>>> >>>>> Kind regards, >>>>> >>>>> Peter Kriens >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> KG> KG> Hello Everybody :) >>>>> >>>>> KG> We're looking at using an existing bundle repository or >>>>> KG> implementing our own. The spec itself, in the spirit of all >>>>> OSGi >>>>> KG> specs, is very nicely done. The statement "The current >>>>> repository >>>>> KG> is still in its infancy." refers to the repository instance >>>>> hosted >>>>> KG> at www2.osgi.org or the specification itself? If it is the >>>>> latter >>>>> KG> then is there an expected date of finalization? The header >>>>> page >>>>> KG> for the spec defines it as "Draft"... The last edit appears >>>>> to be >>>>> KG> two years ago. Also, we use Concierge. Are there any R3 >>>>> gotchas >>>>> KG> to be aware of if we are to implement a Repository Admin? >>>>> KG> Finally as a suggestion it would be helpful to include a >>>>> License >>>>> KG> header as a required field for bundle metadata. In looking >>>>> KG> through implementations of repositories >>>>> KG> (ex http://www2.osgi.org/Repository/HomePage? >>>>> cmd=inspect&id=org.knopflerfish.bundle.bundlerepository/2.0.0 >>>>> <http://www2.osgi.org/Repository/HomePage? >>>>> cmd=inspect&id=org.knopflerfish.bundle.bundlerepository/2.0.0>) >>>>> KG> it is not clear initially how bundles are licensed. >>>>> >>>>> KG> Thanks! >>>>> KG> ken >>>>> >>>>> >>>>> KG> >>>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] <mailto:[email protected]> >>>> http://www2.osgi.org/mailman/listinfo/osgi-dev >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> http://www2.osgi.org/mailman/listinfo/osgi-dev >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> http://www2.osgi.org/mailman/listinfo/osgi-dev KG> _______________________________________________ KG> OSGi Developer Mail List KG> [email protected] KG> http://www2.osgi.org/mailman/listinfo/osgi-dev KG> _______________________________________________ KG> OSGi Developer Mail List KG> [email protected] KG> http://www2.osgi.org/mailman/listinfo/osgi-dev KG> _______________________________________________ KG> OSGi Developer Mail List KG> [email protected] KG> http://www2.osgi.org/mailman/listinfo/osgi-dev -- Peter Kriens Tel +33467542167 9C, Avenue St. Drézéry AOL,Yahoo: pkriens 34160 Beaulieu, France ICQ 255570717 Skype pkriens Fax +1 8153772599 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
