Rick Litton wrote:
Richard S. Hall wrote:
I am not sure what you mean by "m_local" points to .felix cache
instead
of "physical" repository...
Essentially, what's happening is that the version of the resource
fetched using LocalRepositoryImpl.getResources() was the current (old)
version of the bundle which I was trying to update. So I assumed that
this class acts as a wrapper of the bundle cache. This seems to be a
logical assumption since the class constructor is
LocalRepositoryImpl(BundleContext context) and its initialize() method
basically adds cached bundles to the m_localResourceList list.
Well, the only thing LocalRepositoryImpl does is make all installed
bundles look like a OBR repository of resources. This is done by
converting the manifest of each installed bundle into Resource objects.
That's all. It really has nothing to do with the bundle cache. I guess,
if I understand correctly, that this is what you have discovered. :-)
-> richard
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Friday, March 02, 2007 6:08 AM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
[EMAIL PROTECTED] wrote:
FW: Leveraging OBR's generic dependency mechanismHi Felix,
One issue I encountered was with the LocalRepositoryImpl. I may have
it wrong but apparently its m_local variable points to the .felix
cache instead of the actual "physical" repository. To resolve this
issue, I had to create a "map" of the repository so that resources can
be discovered and eventually the actual bundles are installed.
I am not sure what you mean by "m_local" points to .felix cache instead
of "physical" repository...
-> richard
I also found that the getURL method of the resource returns null but
that was overcome with this workaround. Although some more work
remains to be completed, overall the direction looks okay.
And to those who will be at EclipseCon next week, I hope to meet up
with you at the conference!
Best regards.
Rick
