You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by rl...@sbcglobal.net on 2007/03/02 07:20:56 UTC
Re: Leveraging OBR's generic dependency mechanism
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
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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:heavy@ungoverned.org]
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" <rl...@sbcglobal.net>
> To: <fe...@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"
>> <Fe...@day.com>
>> To: <fe...@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 <Ri...@ktd-kyocera.com> 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: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] 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, rl16783@sbcglobal.net <rl...@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
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>
>>
>>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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" <rl...@sbcglobal.net>
> To: <fe...@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"
>> <Fe...@day.com>
>> To: <fe...@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 <Ri...@ktd-kyocera.com> 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: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] 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, rl16783@sbcglobal.net <rl...@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
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>
>>
>>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <rl...@sbcglobal.net>.
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...
Thanks!
Rick Litton
----- Original Message -----
From: "Rick Litton" <rl...@sbcglobal.net>
To: <fe...@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" <Fe...@day.com>
> To: <fe...@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 <Ri...@ktd-kyocera.com> 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: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] 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, rl16783@sbcglobal.net <rl...@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
>>> >
>>> >
>>> >
>>>
>>
>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <rl...@sbcglobal.net>.
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" <Fe...@day.com>
To: <fe...@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 <Ri...@ktd-kyocera.com> 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: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] 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, rl16783@sbcglobal.net <rl...@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
>> >
>> >
>> >
>>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
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 <Ri...@ktd-kyocera.com> 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: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] 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, rl16783@sbcglobal.net <rl...@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
> >
> >
> >
>
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] 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, rl16783@sbcglobal.net <rl...@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
>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
Hi Rick,
Thanks for the update.
Just being curious, what exactly did you patch in InstallerImpl (and
ResolverImpl) ?
Regards
Felix
On 3/2/07, rl16783@sbcglobal.net <rl...@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
>
>
>
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Exactly! Thanks for the confirmation. At least I'm on the right track.
;)
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Friday, March 02, 2007 12:05 PM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
Rick Litton wrote:
> Richard S. Hall wrote:
>
>
>> I am not sure what you mean by "m_local" points to .felix cache
>>
> instead
>
>> of "physical" repository...
>>
>
> Essentially, what's happening is that the version of the resource
> fetched using LocalRepositoryImpl.getResources() was the current (old)
> version of the bundle which I was trying to update. So I assumed that
> this class acts as a wrapper of the bundle cache. This seems to be a
> logical assumption since the class constructor is
> LocalRepositoryImpl(BundleContext context) and its initialize() method
> basically adds cached bundles to the m_localResourceList list.
>
Well, the only thing LocalRepositoryImpl does is make all installed
bundles look like a OBR repository of resources. This is done by
converting the manifest of each installed bundle into Resource objects.
That's all. It really has nothing to do with the bundle cache. I guess,
if I understand correctly, that this is what you have discovered. :-)
-> richard
> Rick Litton
>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Friday, March 02, 2007 6:08 AM
> To: felix-dev@incubator.apache.org
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
> rl16783@sbcglobal.net wrote:
>
>> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>
>> 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 am not sure what you mean by "m_local" points to .felix cache
instead
> of "physical" repository...
>
> -> richard
>
>
>> 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
>>
>>
>>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Rick Litton wrote:
> Richard S. Hall wrote:
>
>
>> I am not sure what you mean by "m_local" points to .felix cache
>>
> instead
>
>> of "physical" repository...
>>
>
> Essentially, what's happening is that the version of the resource
> fetched using LocalRepositoryImpl.getResources() was the current (old)
> version of the bundle which I was trying to update. So I assumed that
> this class acts as a wrapper of the bundle cache. This seems to be a
> logical assumption since the class constructor is
> LocalRepositoryImpl(BundleContext context) and its initialize() method
> basically adds cached bundles to the m_localResourceList list.
>
Well, the only thing LocalRepositoryImpl does is make all installed
bundles look like a OBR repository of resources. This is done by
converting the manifest of each installed bundle into Resource objects.
That's all. It really has nothing to do with the bundle cache. I guess,
if I understand correctly, that this is what you have discovered. :-)
-> richard
> Rick Litton
>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Friday, March 02, 2007 6:08 AM
> To: felix-dev@incubator.apache.org
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
> rl16783@sbcglobal.net wrote:
>
>> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>
>> 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 am not sure what you mean by "m_local" points to .felix cache instead
> of "physical" repository...
>
> -> richard
>
>
>> 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
>>
>>
>>
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Richard S. Hall wrote:
> I am not sure what you mean by "m_local" points to .felix cache
instead
> of "physical" repository...
Essentially, what's happening is that the version of the resource
fetched using LocalRepositoryImpl.getResources() was the current (old)
version of the bundle which I was trying to update. So I assumed that
this class acts as a wrapper of the bundle cache. This seems to be a
logical assumption since the class constructor is
LocalRepositoryImpl(BundleContext context) and its initialize() method
basically adds cached bundles to the m_localResourceList list.
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Friday, March 02, 2007 6:08 AM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
rl16783@sbcglobal.net wrote:
> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>
> 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 am not sure what you mean by "m_local" points to .felix cache instead
of "physical" repository...
-> richard
> 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
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
rl16783@sbcglobal.net wrote:
> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>
> 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 am not sure what you mean by "m_local" points to .felix cache instead
of "physical" repository...
-> richard
> 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
>
>