That's cool, Richard. I'm at the EclipseCon conference and will definitely start on this right away after discussing a few things with Felix and whoever else is interested in contributing. Regards,
Rick -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Mon 3/5/2007 7:33 AM To: felix-dev@incubator.apache.org Subject: Re: Leveraging OBR's generic dependency mechanism Rick Litton wrote: > Hi all, > > Just to add to my response below, I was actually thinking along the > lines of implementing JSR 124 (J2EE Client Provisioning) based on > OBR. I know that provisioning is becoming a hot topic particularly > within the Eclipse community where there are discussions on enhancing > the Upgrade Manager feature. I'm not sure if there is interest among > the Felix community though... I am definitely interested in improving this area for Felix...adding this type of support in another layer on top of OBR sounds like a good idea to me. -> richard > > Thanks! > > Rick Litton > > ----- Original Message ----- From: "Rick Litton" <[EMAIL PROTECTED]> > To: <felix-dev@incubator.apache.org> > Sent: Saturday, March 03, 2007 3:04 AM > Subject: Re: Leveraging OBR's generic dependency mechanism > > >> Hi Felix, >> >> I certainly would like to contribute (not take over) to this feature >> if that's ok. Perhaps we can define some more use cases so that >> Assembly could accommodate other requirements. What do you think? >> >> Rick >> >> ----- Original Message ----- From: "Felix Meschberger" >> <[EMAIL PROTECTED]> >> To: <felix-dev@incubator.apache.org> >> Sent: Saturday, March 03, 2007 1:39 AM >> Subject: Re: Leveraging OBR's generic dependency mechanism >> >> >>> Hi Rick, >>> >>> Ok, thanks for the information. >>> >>> BTW: As noted earlier I attached the Assembly support stuff to JIRA >>> http://issues.apache.org/jira/browse/FELIX-217. Is there any >>> interest to >>> take this over as a contribution to the Felix project ? Otherwise, I >>> would >>> close the issue again. Thanks for any feedback. >>> >>> Regards >>> Felix >>> >>> On 3/2/07, Rick Litton <[EMAIL PROTECTED]> wrote: >>>> >>>> Felix Meschberger wrote: >>>> >>>> > Just being curious, what exactly did you patch in InstallerImpl (and >>>> > ResolverImpl) ? >>>> >>>> Hi Felix, >>>> >>>> Actually, I created a class called LocalResolverImpl which extends >>>> from >>>> ResolverImpl. It was meant to deal with the categorization of bundles >>>> into "updatable bundles" and "installable bundles" and to search for a >>>> "capable resource" by matching capabilities and requirements. This >>>> created the potential for intercepting the update process at a certain >>>> point sometime later. The InstallerImpl was actually built from the >>>> ground up although it pretty much also does the install operation. >>>> Similar to your class, it delegates the actual work of deploying the >>>> updated or new bundle to the resolver and manages the startlevel of >>>> these bundles. >>>> >>>> Regards. >>>> >>>> Rick Litton >>>> >>>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >>>> Felix >>>> Meschberger >>>> Sent: Friday, March 02, 2007 12:52 AM >>>> To: felix-dev@incubator.apache.org >>>> Subject: Re: Leveraging OBR's generic dependency mechanism >>>> >>>> Hi Rick, >>>> >>>> Thanks for the update. >>>> >>>> Just being curious, what exactly did you patch in InstallerImpl (and >>>> ResolverImpl) ? >>>> >>>> Regards >>>> Felix >>>> >>>> On 3/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>>> > >>>> > FW: Leveraging OBR's generic dependency mechanismHi Felix, >>>> > >>>> > Felix Meschberger wrote on 2/22/2007: >>>> > >>>> > >Hi, >>>> > >>>> > >> Apparently, there is only a single queueHandler >>>> > >> thread which handles the events. I must be missing something. >>>> > >>>> > > The thread is started at the end of the AssemblyManager.start >>>> method, >>>> > > which >>>> > > first gathers existing bundles to jump start the Assembly Manager >>>> with >>>> > > simulated events for them. The AssemblyManager.start method itself >>>> is >>>> > > called >>>> > > from AssemblyActivator (the BundleActivator) start method... >>>> > >>>> > >> My question is how does the installer handle direct and >>>> > >> indirect dependencies if those dependencies are also required >>>> to be >>>> > >> updated? >>>> > >>>> > > Ok. This depends. If the dependencies are included with the >>>> assembly, >>>> > > there >>>> > > lifecycle is controlled through the Assembly Bundle. If the >>>> dependencies >>>> > > are >>>> > > not included in the assembly, and an OBR is used to install the >>>> bundles, >>>> > > the >>>> > > dependencies will be resolved by the OBR and just started by the >>>> > > AssemblyManager (these are the requiredResources of the Resolver). >>>> They >>>> > > are >>>> > > not further managed by the AssemblyManager, they are just there. >>>> > >>>> > > If the dependencies not managed by the AssemblyManage happen to >>>> require >>>> > an >>>> > > update due to updated requirements of managed bundles, these >>>> updates >>>> may >>>> > > take place as a "side effect" of OBR bundle resolution. >>>> > >>>> > > So for complete management, it might be a good idea to include all >>>> > > dependencies as far as possible in the Assembly. Again: This is a >>>> > > management >>>> > > task based on a management decision outside of the framework >>>> and not >>>> a >>>> > > technically required task ! >>>> > >>>> > > Regards >>>> > > Felix >>>> > >>>> > I should have responded much earlier, but instead I would just >>>> like to >>>> > provide you with a quick update. Apparently, our automated update >>>> process >>>> > using OBR seems to be working. Thanks to your examples and by >>>> following >>>> > Richard's original suggestion consisting of 4 steps, I was able to >>>> build >>>> > a >>>> > customized version of InstallerImpl and ResolverImpl. The whole >>>> process >>>> > is >>>> > triggered when a local repository is detected. The approach I have >>>> taken >>>> > was to identify updatable bundles (those that have an older version) >>>> from >>>> > the installable bundles (those that are entirely new) up front. By >>>> > matching >>>> > capabilities and requirements, I was then able to build a list of >>>> > resources >>>> > that could be installed, lining them up in a stack, to ensure >>>> that the >>>> > required dependencies pulled in were installed first. So far the >>>> update >>>> > seems to work provided that there were no cyclical dependencies >>>> which >>>> in >>>> > our >>>> > case, we took the effort to avoid. Of course, this doesn't sound so >>>> ideal >>>> > but it's currently the situation which I know will improve over time >>>> as >>>> > the >>>> > benefits of a service architecture are fully realized. >>>> > >>>> > One issue I encountered was with the LocalRepositoryImpl. I may >>>> have >>>> it >>>> > wrong but apparently its m_local variable points to the .felix cache >>>> > instead >>>> > of the actual "physical" repository. To resolve this issue, I >>>> had to >>>> > create >>>> > a "map" of the repository so that resources can be discovered and >>>> > eventually >>>> > the actual bundles are installed. I also found that the getURL >>>> method >>>> of >>>> > the resource returns null but that was overcome with this >>>> workaround. >>>> > Although some more work remains to be completed, overall the >>>> direction >>>> > looks >>>> > okay. >>>> > >>>> > And to those who will be at EclipseCon next week, I hope to meet up >>>> with >>>> > you >>>> > at the conference! >>>> > >>>> > Best regards. >>>> > Rick >>>> > >>>> > >>>> > >>>> >>> >> >> >> > >
