"Richard S. Hall" <[EMAIL PROTECTED]> writes:

> You apparently removed my smiley on that line...

Sorry, I didn't mean to dash the friendly sentiment. I understood that
you meant to harm.

> Just keep in mind that there is difference between being dependent
> on a framework or being dependent on a bundle. Being dependent on a
> framework is not so good because you are stuck with the framework,
> being dependent on a bundle is not so bad, because it can run on any
> framework.

Well, in this case, I'm having to depend on some private
implementation details of the Felix bundlerepository bundle, but note
its bundle plugin configuration:

  <Export-Package>org.osgi.service.obr</Export-Package>
  <Private-Package>org.kxml2.*,org.xmlpull.*,
                   org.apache.felix.bundlerepository.*</Private-Package>

Note that the org.apache.felix.bundlerepository is private. It's not
enough that I can load the bundle. My code has to refer directly to
some things in the org.apache.felix.bundlerepository package.

To be more specific, I'm (temporarily, for experimentation) trying to
hoist the LocalResourceImpl class into my own code, so that I can move
from a Bundle to a Resource. Here are some of the imports necessary to
get this to compile:

  import org.apache.felix.bundlerepository.ResourceImpl;
  import org.apache.felix.bundlerepository.R4Import;
  import org.apache.felix.bundlerepository.R4Package;
  import org.apache.felix.bundlerepository.CapabilityImpl;
  import org.apache.felix.bundlerepository.PropertyImpl;
  import org.apache.felix.bundlerepository.RequirementImpl;

These are all bits and pieces of the parsing and mapping done in
LocalResourceImpl's initialize() method. Even then, I had to comment
out the calls to CapabilityImpl's addP() method, which is
protected. This feels too low-level for API-consuming code.

(I'm working on my experiment as I type, so I can't report yet whether
this is going to work out.)

> If you use OBR to try to resolve your bundles, then you can get more
> information about why it cannot resolve.

That's what I'm trying to do here, but the only way I can see to do
this with the existing interface is to create the ad-hoc local
repository.xml before installing the bundle. We need some way to get
from a Bundle to a Resource, and then I'd agree with the suggestion to
"use OBR" for resolution.

> Seems like it would be better to just have:
>
>    public static Resource convertToResource(Bundle bundle);

Yes, that would be fine.

> I think the issue there was to not become dependent on a specific
> filter type. You could imagine OBR implementations that used a
> different filter representation.

Fair enough.

-- 
Steven E. Harris

Reply via email to