felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Köhler <kristian.koeh...@googlemail.com>
Subject Re: Problems with bundle resolving with bundle repository - endless resolving
Date Tue, 24 Mar 2009 09:32:04 GMT
Hi Richard

did you find some time to look into this issue? ;-)

Thanks

Kristian

2009/3/6 Richard S. Hall <heavy@ungoverned.org>:
> Thanks. I will try to get to it (and some of your other OBR issues), but I
> am fairly busy the next week or so, so be patient, but feel free to bug me
> nicely. :-)
>
> -> richard
>
> On 03/06/2009 09:09 AM, Kristian Köhler wrote:
>>
>> Hi
>>
>> I opened an issue https://issues.apache.org/jira/browse/FELIX-977
>>
>> The attached file should reproduce the problem.
>>
>> Thanks
>>
>> Kristian
>>
>> 2009/3/6 Richard S. Hall<heavy@ungoverned.org>
>>
>>
>>>
>>> Perhaps you could create a JIRA issue and I could try to look into it.
>>>
>>> I will probably need you to make a reproducible example available to me
>>> somehow.
>>>
>>> ->  richard
>>>
>>>
>>> On 03/06/2009 03:08 AM, Kristian Köhler wrote:
>>>
>>>
>>>>
>>>> Hi
>>>>
>>>> I encountered problems while resolving rependencies via the bundle
>>>> repository.
>>>>
>>>> Here is the scenario:
>>>> I have a simple obr file with a resource definition which has an
>>>> unresolved
>>>> dependency (the file is attached to this mail). In this file the
>>>> resource
>>>> with the name "org.springframework.core" has a requirement for the
>>>> "org.apache.commons.logging".
>>>> When I start felix with the obr repository location poniting to that
>>>> file
>>>> and type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the
>>>> following:
>>>>
>>>> --- 8<   ---
>>>> Unsatisfied requirement(s):
>>>> ---------------------------
>>>>    (&(package=org.springframework.context)(version>=2.5.0))
>>>>       Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>>>>
>>>>
>>>> (&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>>>>       Spring Context
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Beans
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>>       Spring Core
>>>> --- 8<   ---
>>>>
>>>> I seems to me that felix tries to resolve the bundle "Spring Core" more
>>>> than
>>>> once ;-)
>>>>
>>>> The wrong unsatisfied dependency information can easily be fixed when
>>>> checking for existing information in the current list before added it
>>>> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is
>>>> only
>>>> a
>>>> workaround for the problem of 'double resolving' (I also tried with a
>>>> larger
>>>> project and the resolving seems to run 'endless').
>>>>
>>>> In the ResolverImpl I found a statement which 'causes' my problem but
>>>> there
>>>> is also a comment for the code.
>>>>
>>>> --- 8<   ---
>>>>         // If the resource did not resolve, then remove it from
>>>>         // the resolve set, since to keep it consistent for iterative
>>>>         // resolving, such as what happens when determining the best
>>>>         // available candidate.
>>>>         if (!result)
>>>>         {
>>>>             m_resolveSet.remove(resource);
>>>>         }
>>>> --- 8<   ---
>>>>
>>>> Removing the line solved my problem but I'm not sure if I'm running in
>>>> new
>>>> ones...
>>>>
>>>> Can someone help? ;-)
>>>>
>>>> Thanks
>>>>
>>>> Kristian
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>>
>



-- 
http://www.kkoehler.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message