felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Problems with bundle resolving with bundle repository - endless resolving
Date Fri, 06 Mar 2009 14:04:04 GMT
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


Mime
View raw message