felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-977) Bundle resolving runs extreme long
Date Mon, 30 Mar 2009 13:50:50 GMT

    [ https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693769#action_12693769
] 

Richard S. Hall commented on FELIX-977:
---------------------------------------

Ok, as far as I can see, I forgot to add the line to add a resource to the failed set when
it is removed from the resolve set due to a resolution failure. I have attached a new patch
that adds this line and I tested it locally again and it is still correctly resolving dependencies.
Let me know if it works for you. Thanks.

> Bundle resolving runs extreme long
> ----------------------------------
>
>                 Key: FELIX-977
>                 URL: https://issues.apache.org/jira/browse/FELIX-977
>             Project: Felix
>          Issue Type: Bug
>          Components: Bundle Repository (OBR)
>            Reporter: Kristian Koehler
>         Attachments: bundlerepo-patch-2009_03_26.txt, FELIX-977-new.txt, FELIX-977.txt,
myrepo.xml
>
>
> 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.
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...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message