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
