Steven E. Harris wrote:
As I mentioned, I finished hoisting LocalResourceImpl into my code
just for the sake of mapping a Bundle to a Resource. I then had to
edit bundlerepository/pom.xml to export the would-be private
org.apache.felix.bundlerepository package from the bundlerepository
bundle.
After all that, I can declare
SUCCESS!
Well, that is good news.
Once the first bundle is installed, I created a LocalResourceImpl
instance around it. Of course, I'd rather call on some mapping
function like you suggested to get a Resource from this Bundle. Using
a ServiceTracker¹, I got ahold of the RepositoryAdmin service, added
my local repository.xml file, and asked for a Resolver instance.
Next I added my Bundle-based Resource to the Resolver, told it to
resolve() and, upon success, told it to deploy(). It looks like it
figures out not to install the original Bundle again, but obviously
even that is extra work: It would be nice if there was some way to add
/requirements/ to a Resolver rather than Resources themselves (as in
this case, I don't want the added Resource to be deployed, as it's
already installed), but perhaps that's what
RepositoryAdmin.discoverResources() is for.
I am not sure why you want to add requirements or see adding a Resource
to the resolver as extra work. Assuming we had the static method in
question, the solution to your situation would be a process like:
1. Resource localRes = OBR.bundleToResource(bundle);
2. Resolver resolver = repoAdmin.getResolver();
3. resolver.add(localRes);
4. resolver.resolver();
5. resolver.deploy();
This seems pretty simple. How would accessing the requirements make this
any better or simpler?
Or are you worried about making the OBR resolver code simpler? In that
case it doesn't matter because OBR has to deal with the case that some
things might be locally installed no matter what.
Based on the success here, this process can be made to work, but it's
a matter of finding the right place to expose this Bundle->Resource
mapping. Again, I'd prefer that such a mapping be available as part of
the OSGi OBR API, but for now I'd settle for a
Felix-specific-but-publicly-exposed solution as well.
Ok, thanks for looking into this, when I get the time I will look into
it. I created a JIRA issue to keep track of it.
Footnotes:
¹ Pulling in the org.osgi.compendium bundle has an unfortunate
dependency on the javax.servlet.http package, though I couldn't
trace it back to the org.osgi.compendium/pom.xml file.
I think this is due to the fact that compendium contains HTTP Service,
which has a dependency on servlet. If you want to avoid that, then you
can create your own tracker JAR that only contains the tracker...this
would be really, really easy to do with the new maven-bundle-plugin.
-> richard
