You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Guillaume Nodet (JIRA)" <ji...@apache.org> on 2010/03/01 11:24:05 UTC
[jira] Resolved: (FELIX-692) OBR should provide an API for
resolving bundles dependencies regardless of locally installed bundles
[ https://issues.apache.org/jira/browse/FELIX-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved FELIX-692.
-----------------------------------
Resolution: Fixed
I think Richard's issue about the API has now been solved, so I'm closing this issue again.
Please reopen if there are further problems.
Arjun, for the URL/URI problem, when building a URL, you need to have an implementation of a URL handler, even if you don't open the stream. We could use something like obr://local/ and reuse the existing URL handler, but I'm not actuallly sure it's worth it given the current api.
> 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.