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. 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 > >
