On 18 February 2010 00:43, David Jencks <[email protected]> wrote:
>
> On Feb 17, 2010, at 10:22 AM, Alasdair Nottingham wrote:
>
>> Hi,
>>
>> I've delivered a fix to the problem I saw in ARIES-174, so it now
>> correctly resolves against the Application-Content rather than the
>> bundles in the archive. This does reveal/introduce a different problem
>> in that we don't resolve against the bundles in the archive, but I'll
>> look into that tomorrow and send an update.
>
> Is the behavior you expect (resolving against the application-content)
> specified somewhere?

Yes, it is specified here: http://incubator.apache.org/aries/applications.html

>
> What would happen if we stuff resources for all of the application content
> (like you do) and the bundles in the archive (like I did) into the resolver?
>  I was under the (untested) impression that obr would resolve the supplied
> resources against each other.
>

It attempts to resolve all the resources that have been added to the
resolver. So
Let's assume we have the following:

archive:
Application-Content: a, b, z
a.jar
b.jar
c.jar
d.jar
e.jar


a depends on b
b depends on c
d depends on q
e depends on r
z depends on w

If I add a, b, z in as resources I would end up with a, b, c, z, w. If
I add the bundles in the Application-Content, and the bundles inside
the archive I would end up with: a, b, c, d, e, q, r, w, z which would
result in too much being provisioned, and content that wasn't asked
for.

Note if no Application-Content is specified it would default to a, b, c, d, e

I'm working on a fix today that will correctly resolve against the
bundles in the archive.

>>
>> In addition I managed to get the failing itest running, so I've
>> committed a fix that should fix that.
>>
>> We really need to get some debug into the resolver, I'm not familiar
>> with SLF4J though, perhaps we should have a page on the wiki to
>> describe how we should use it?
>>
>
> I tend to prefer jpda debugging to logging except to explain errors in
> detail.... but what kind of logging are you thinking of?  For me slf4j type
> logging is so ingrained I don't know how to explain how to use it.
>

I agree I prefer jpda, but it often isn't an option. I frequently just
get a set of trace/log files
from customers using the code and I need to debug from that as the
customer's application/setup
is not available.

> I'll put a logger in and a dumb example use, maybe that will help.
>

Thanks

> thanks
> david jencks
>
>> Alasdair
>>
>> On 17 February 2010 10:56, Alasdair Nottingham <[email protected]> wrote:
>>>
>>> I've found a bug in the resolver. The resolver doesn't resolve the
>>> application content, but it resolves the bundles contained inside the
>>> application archive. I'm working on a fix and I'll commit it under
>>> ARIES-174.
>>>
>>> Alasdair
>>>
>>> On 17 February 2010 10:11, Alasdair Nottingham <[email protected]> wrote:
>>>>
>>>> I would advise against exporting any implementation package from a
>>>> bundle.
>>>>
>>>> Alasdair
>>>>
>>>> On 16 February 2010 20:00, David Jencks <[email protected]> wrote:
>>>>>
>>>>> I committed a basic OBR-backed AriesApplicationResolver, see ARIES-174.
>>>>>
>>>>> To get the itest to run it looks like you need to build
>>>>> bundlerepository
>>>>> locally, I'm not quite sure why.
>>>>>
>>>>> I'm seeing the new MinimumImportsTest itest fail, I haven't looked into
>>>>> why.
>>>>>
>>>>> This might be an overly naive implementation, so if I missed big pieces
>>>>> of
>>>>> functionality and someone wants to start over I won't mind :-).
>>>>>
>>>>> I'd also appreciate some advice from more-osgi-experienced developers
>>>>> as to
>>>>> whether it's appropriate to export the main resolver class or if it
>>>>> should
>>>>> be hidden in the impl directory.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alasdair Nottingham
>>>> [email protected]
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> [email protected]
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> [email protected]
>
>



-- 
Alasdair Nottingham
[email protected]

Reply via email to