FYI, I just committed some changes in revision 964138 that address
this issue (using the isLocals() { return false; } solution). Hope the
approach works for everybody.
Jarek
On Tue, Jun 29, 2010 at 4:26 AM, Alasdair Nottingham
<n### @apache.org> wrote:
I don't think a two step will work because the local repo results
don't get added into the resolve result so it would still fail.
I think if we took the locals repo and wrapped them to not be locals,
I.e. IsLocal returns false, then we could do what we want.
Alasdair
On Monday, June 28, 2010, Lin Sun <linsu### @gmail.com> wrote:
> Hi
>
> This seems reasonable to me. Does this mean we need to run the
felix
> bundle repository Resolver.resolve() twice?
>
> 1. generate the required resource for deployment.mf, without
using
> local repo, assuming we need to run Resolver.resolve() then
> Resolver.getRequiredResources() to get the required resource.
> 2. after adding the local repo, try to see the result of
Resolver.resolve().
>
> Thanks
>
> Lin
>
> On Mon, Jun 28, 2010 at 1:11 PM, Jarek Gawor
<jgaw### @gmail.com> wrote:
>> So, what I think OBRAriesResolver should really do, is use
all three
>> types of repositories (system, local, and user-defined) and
configure
>> the OBR resolver somehow to include local resources in the
resolved
>> set (instead of pruning them out).
>>
>> WDYT?
>>
>> Jarek
>>
>> On Fri, Jun 25, 2010 at 12:43 PM, Alasdair Nottingham
<no### @apache.org> wrote:
>>> Hi,
>>>
>>> I had deliberately excluded the local repository from the
resolve when
>>> I update the resolver. The reason I excluded it is
because if the
>>> resource is local you don't get information about the
bundle back so
>>> you cannot store it in the deployment.mf. The result is
that the
>>> application cannot be deployed to a different framework.
I want to go
>>> back to removing the local repo so we can get the
deployment.mf to
>>> correctly reflect the bundles that are needed to run the
application.
>>>
>>> Alasdair
>>
>
--
Alasdair Nottingham
no### @apache.org
