Return-Path: Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: (qmail 8434 invoked from network); 6 Mar 2009 14:10:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Mar 2009 14:10:00 -0000 Received: (qmail 27149 invoked by uid 500); 6 Mar 2009 14:09:59 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 27115 invoked by uid 500); 6 Mar 2009 14:09:59 -0000 Mailing-List: contact users-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@felix.apache.org Delivered-To: mailing list users@felix.apache.org Received: (qmail 27104 invoked by uid 99); 6 Mar 2009 14:09:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Mar 2009 06:09:58 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kristian.koehler@googlemail.com designates 209.85.218.172 as permitted sender) Received: from [209.85.218.172] (HELO mail-bw0-f172.google.com) (209.85.218.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Mar 2009 14:09:48 +0000 Received: by bwz20 with SMTP id 20so395783bwz.22 for ; Fri, 06 Mar 2009 06:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=MNyGpZ13hAqMZx8qC/F9njDbUteoKJ3IOOnzPyJHzrA=; b=LDJEAAhs681OKsjppUQyj4zfWmqECvMQcS8YdVxofBXl6139PtCJvgWjrqUbRQYTYM hMxrb9rqXYVVJTH/NS4477d0SWCBqDby796sguTyfqS7x8IdZfeW1YlUIpqWnXmP+hiz 7EGb9xu3L3kpPEJSYOGxCAnCfesiB7TyN34w4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uTqRdiEyr+g3b9zt23KG2h8lM28w5tvqW5DsTccULYtjAwkA3uYKeN2WloMrn72zAM /DkiAUc110XPRNJlnLL0JlAVc06so4HD1CEJNe99Z4zg7f15qxaLJP8OB+PnN70bZ7bf L1BUd89j1A3QF/Et/NoVWWdhdowO7/V+0fK9I= MIME-Version: 1.0 Received: by 10.223.114.79 with SMTP id d15mr2047047faq.88.1236348568134; Fri, 06 Mar 2009 06:09:28 -0800 (PST) In-Reply-To: <49B12D54.10705@ungoverned.org> References: <49B12D54.10705@ungoverned.org> Date: Fri, 6 Mar 2009 15:09:28 +0100 Message-ID: Subject: Re: Problems with bundle resolving with bundle repository - endless resolving From: =?ISO-8859-1?Q?Kristian_K=F6hler?= To: users@felix.apache.org Content-Type: multipart/alternative; boundary=001636c5967238e625046473d5ef X-Virus-Checked: Checked by ClamAV on apache.org --001636c5967238e625046473d5ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 > 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=F6hler 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 resourc= e >> 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 fil= e >> and type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the >> following: >> >> --- 8< --- >> Unsatisfied requirement(s): >> --------------------------- >> (&(package=3Dorg.springframework.context)(version>=3D2.5.0)) >> Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT >> >> (&(package=3Dorg.apache.commons.logging)(version>=3D1.0.4)(!(version>=3D= 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 on= ly >> 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 n= ew >> 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 > > --=20 http://www.kkoehler.com --001636c5967238e625046473d5ef--