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
