felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: Leveraging OBR's generic dependency mechanism
Date Fri, 02 Mar 2007 08:51:30 GMT
Hi Rick,

Thanks for the update.

Just being curious, what exactly did you patch in InstallerImpl (and
ResolverImpl) ?


On 3/2/07, rl16783@sbcglobal.net <rl16783@sbcglobal.net> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message