Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <1256203172.630811270122628411.JavaMail.jira@brutus.apache.org>
Date: Thu, 1 Apr 2010 11:50:28 +0000 (UTC)
From: "Carsten Ziegeler (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Closed: (FELIX-692) OBR should provide an API for resolving
 bundles dependencies regardless of locally installed bundles
In-Reply-To: <1364698972.1219238684194.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FELIX-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler closed FELIX-692.
----------------------------------


> OBR should provide an API for resolving bundles dependencies regardless of locally installed bundles
> ----------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-692
>                 URL: https://issues.apache.org/jira/browse/FELIX-692
>             Project: Felix
>          Issue Type: Improvement
>          Components: Bundle Repository (OBR)
>            Reporter: Arjun Panday
>            Assignee: Guillaume Nodet
>            Priority: Minor
>             Fix For: bundlerepository-1.6.0
>
>         Attachments: bundlerepository.tgz
>
>
> Currently the dependencies that are installed locally are stripped from the OBR Resolver response, because it is assumed that the new bundles are to be installed locally. But i cannot use the OBR to launch a separate JVM or store the result for later reference... 
> It would be interesting to have a pure Resolver API, distinct from the OBR's "installation process".
> And/Or, as Richard Hall suggested, the OBR could provide better control over the repositories used during the resolve process (specifically the local repository).
> (see thread "OBR and the referral tag" in users@felix.apache.org)
> Merely as a hint and for what it's worth, here's how i slightly modified the Resolver in bundlerepository 1.0.3 to serve my purpose (avoid ignoring locally installed bundles):
> @@ -308,6 +309,7 @@ public class ResolverImpl implements Resolver
>       */
>      private List searchLocalResources(Requirement req)
>      {
> +       String systemPackages = (String) m_context.getBundle(0).getHeaders().get("Export-Package");// only match system bundle
>          List matchingCandidates = new ArrayList();
>          Resource[] resources = m_local.getResources();
>          for (int resIdx = 0; (resources != null) && (resIdx < resources.length); resIdx++)
> @@ -315,7 +317,8 @@ public class ResolverImpl implements Resolver
>              Capability[] caps = resources[resIdx].getCapabilities();
>              for (int capIdx = 0; (caps != null) && (capIdx < caps.length); capIdx++)
>              {
> -                if (req.isSatisfied(caps[capIdx]))
> +                if (req.isSatisfied(caps[capIdx])
> +                   && systemPackages.indexOf(caps[capIdx].getName()) != -1) // only match system bundle
>                  {
>                      matchingCandidates.add(resources[resIdx]);
>                  }
> @@ -91,7 +91,7 @@ public class LocalRepositoryImpl implements Repository
>          synchronized (this)
>          {
>              m_snapshotTimeStamp = m_currentTimeStamp = new Date().getTime();
> -            bundles = m_context.getBundles();
> +            bundles = new Bundle[]{ m_context.getBundle(0) }; // only match system bundle... m_context.getBundles();
>          }

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