Thanks for the clearing up Richard! Regarding the use of the word "owner" I guess I meant "maintainer". :)
Regards, Per-Erik Svensson On Thu, Mar 3, 2011 at 7:46 PM, Richard S. Hall <he...@ungoverned.org>wrote: > On 3/3/11 13:39, Per-Erik Svensson wrote: > >> A question to others: Does anyone know who the owner of the bundle >> repository implementation is and what other projects that may depend on >> its >> somewhat awkward details? (Awkward to me that is, I'm sure there are good >> reasons for keeping a parallell interface-hierarchy.) >> > > Apache Felix project and its community members are the "owner". > > Regarding the parallel interfaces, the issue is that the > org.osgi.service.obr package is a "provisional" OSGi API (i.e., they haven't > released a spec yet). There is effort in the OSGi Alliance to finish the OBR > spec, but until it is finalized we at Apache Felix are not at liberty to > make changes to the org.osgi.service.obr API to address deficiencies, since > we don't own it. We addressed some of those limitations in a parallel > structure. Hopefully the Apache-specific API will be able to go away (or be > reduced) once the OSGi Alliance finalizes the OBR API. > > -> richard > > > Regards, >> Per-Erik Svensson >> >> >> On Thu, Mar 3, 2011 at 5:02 PM, Bruce Hartman<bhart...@westell.com> >> wrote: >> >> I have to work this into our own bundle/application management system. >>> Unfortuneatly, I can't use or link to external controls. >>> >>> Since our applications may consist of more than one bundle, I need to >>> create an xml file that links our applications to the list of bundles in >>> the >>> OBR. Should I even use an OBR at this point? I could just put the >>> bundle >>> information in the same xml file and use that information to install, >>> uninstall, update, start and stop applications (manipulating bundles >>> using >>> the bundle context seems trivial) - basically build my own OBR. >>> >>> What direction do you think I should go? Should I use an OBR or make my >>> own? >>> >>> If I should use the OBR, should I be using the RepositoryAdmin service? >>> >>> If I should use RepositoryAdmin, what goes in the parameter (the flags) >>> of >>> the 1.6.2+ Resolver.deploy(int args) method? >>> >>> Thanks for your help, and please let me know if I need to clarify. >>> >>> Bruce >>> >>> P.S. Thanks for the advice Richard. If I can't get this working, I'll >>> look at the source code for the Felix Web Console. However, I suspect >>> that >>> they are not linking to an OBR, but using the bundle context to >>> manipulate >>> the bundles. I'm thinking that since I have the OBR working up to the >>> point >>> that I'm trying to deploy the bundle (if I could only figure out what >>> flags >>> to put in), I may use the bundle context to install the bundle at that >>> point >>> - since I can query the url from the resource from the >>> RepositoryAdmin.discoverResources() call. >>> >>> >>> -----Original Message----- >>> From: Richard S. Hall [mailto:he...@ungoverned.org] >>> Sent: Thursday, March 03, 2011 8:29 AM >>> To: users@felix.apache.org >>> Subject: Re: GUI to control installing bundles from an OBR >>> >>> Doesn't Felix Web Console offer a GUI for OBR as well as for managing >>> bundles? You could look into using that. >>> >>> -> richard >>> >>> On 3/2/11 16:42, Bruce Hartman wrote: >>> >>>> Hi, I'm attempting to create a GUI that will display available bundles, >>>> >>> and whether they are installed, uninstalled, need to be updated, stopped >>> or >>> started, etc. >>> >>>> I'm creating an OBR with all the bundles we will supply. >>>> >>>> My question is open ended - pretty much, "how do I do this". Here is >>>> >>> what I'm planning to do. Please feel free to tell me if I'm on the right >>> track, or if there's a better mechanism. Thanks in advance. >>> >>>> I am planning to get the RepositoryAdmin service, from the Felix bundle >>>> >>> repository 1.6.2, to load my OBR, and install bundles from it (when the >>> user >>> presses the "install" button). >>> >>>> Does this sound like the best way to do this? >>>> >>>> If it does, I have a couple of questions about the Resolver object >>>> (which >>>> >>> I can get from the RepositoryAdmin object): >>> >>>> 1. Where is the Javadocs for the Felix bundle repository - 1.6.2? >>>> 2. The Resolver object has a deploy method. The only documentation for >>>> >>> this that I could find used the deploy(boolean start) method. However, >>> in >>> 1.6.2, the method deploy takes an int. Digging around, I could see that >>> this was for passing in some kind of flags. Is there some documentation >>> for >>> what the flags are and what they mean? Otherwise, would deploy(0) be >>> equal >>> to the old deploy(false)? >>> >>>> Thanks so much for responses. >>>> >>>> Bruce >>>> >>>> >>>> *************************************************************************************** >>> >>>> This e-mail and its attachments are a private communication sent from >>>> >>> Westell Technologies, Inc., >>> >>>> a telecommunications company. Its contents may contain confidential and >>>> >>> proprietary information that is protected. >>> >>>> If you are not the intended recipient, you are hereby notified that any >>>> >>> disclosure, copying, distribution or use of the >>> >>>> information contained in or attached to this message is strictly >>>> >>> prohibited. If you have received this e-mail in error, >>> >>>> please notify the sender by replying to this message, and then delete it >>>> >>> from your system. Thank you. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >>> >>> >>> >>> *************************************************************************************** >>> This e-mail and its attachments are a private communication sent from >>> Westell Technologies, Inc., >>> a telecommunications company. Its contents may contain confidential and >>> proprietary information that is protected. >>> If you are not the intended recipient, you are hereby notified that any >>> disclosure, copying, distribution or use of the >>> information contained in or attached to this message is strictly >>> prohibited. If you have received this e-mail in error, >>> please notify the sender by replying to this message, and then delete it >>> from your system. Thank you. >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >