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
