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
