Christer, Thanks for the help. I ended up using the bindex program against our bundles as the standard. Which brings up another question about RFC 112. On page 13:
"..A specific Resource object can be found with the getResource method. This method takes the repository local id as parameter." "local id" is only mentioned once in the spec, and it's in this sentence. The XML generated by bindex does not contain an id attribute for the repository tag. Is the local id the name? Also, is this list the best place for this sort of question? thanks! ken ----- Original Message ----- From: "Christer Larsson" <[EMAIL PROTECTED]> To: "OSGi Developer Mail List" <[email protected]> Sent: Monday, December 10, 2007 11:46:28 AM (GMT-0500) America/New_York Subject: RE: [osgi-dev] RFC 112 Bundle Repository Questions Ken, The KF repo that we link to from knopflerfish.org is indeed an older version, almost ancient by now ;-) There is also an RFC 112 compatible version available at: http://www.knopflerfish.org/repo/bindex.xml Quite well hidden I'm afraid... This is this repo that is used by: http://www2.osgi.org/Repository/HomePage A move to RFC 112 as the default format on kf.org is on the ToDo. Regards, Christer Makewave http://www.makewave.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ken Gilmer Sent: den 6 december 2007 19:55 To: OSGi Developer Mail List Subject: Re: [osgi-dev] RFC 112 Bundle Repository Questions Thanks for the clarifications Richard. -ken 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 _______________________________________________ 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 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
