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
