felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: OBR Resource from a Bundle (was: Programmatic/non-shell-based interface to OBR)
Date Wed, 07 Feb 2007 15:43:09 GMT

On Feb 6, 2007, at 7:18 PM, Steven E. Harris wrote:

> "Richard S. Hall" <heavy@ungoverned.org> writes:
>> After talking with Peter Kriens a bit about it, I think when I get
>> the time to work on it, I will just create a OBR-impl-specific
>> package to export.
> I'm raising this thread again, in reference to JIRA issue FELIX-178:
>   http://issues.apache.org/jira/browse/FELIX-178
> As more team members join my project, I'm looking to solidify how I'm
> going to move forward with the conversion from a Bundle to an OBR
> Resource.
> I have a cobbled-together copy of LocalResourceImpl with a public
> constructor that takes a Bundle as an argument, mostly copied from the
> Felix class LocalRepositoryImpl.LocalResourceImpl. However, it
> requires me to fiddle with the bundlerepository POM's Export-Package
> and Private-Package directives, forcing us all to use in-house builds
> of the Felix bundle.
>> The OBR spec is essentially OSGi independent, so it seems to make
>> sense to keep it that way. Even though they will be exposed as
>> OBR-impl packages, you can still use those on other frameworks with
>> other OBR implementations, so it seems reasonable...and with the new
>> bundle plugin, you can easily just extract that package and include
>> it in your own bundle if you want, to make it completely independent
>> of Felix' OBR impl.
> I experimented with this today, and found that I also have to drag in
> the kxml2 stuff, or start tailoring my own bundle's dependencies to
> match what would have been bundlerepository's dependencies.
> I'd rather put my effort toward actually implementing this capability
> in Felix so that I could contribute the changes and get them rolled
> into the official source tree.
> My problem is figuring out where to put the new package and class. We
> need a class because we're talking about what should be a static
> method. It should take a Bundle as an argument and return a
> Resource. The function signature could use all OBR types; nothing
> Felix-specific need be mentioned.
> However, the implementation would probably reuse the guts of
> LocalRepositoryImpl.LocalResourceImpl, provided these parsing and
> conversion functions haven't moved into Felix proper with the recent
> filter development.
> Again, I'm willing to do the typing and testing, but I need some
> aesthetic direction from those here with the organizational
> vision. Should this new class live under something like
> org.osgi.service.obr.util? Or maybe under something like
> org.apache.felix.bundlerepository.obrext?
> We could wander into circular dependencies, too. The interface depends
> upon OBR, but the implementation depends upon the guts of the Felix
> bundlerepository stuff, which in turn depends upon OBR. That makes me
> think that this conversion function belongs with the Felix code, but
> none of those packages are exported at the moment.ยน
> Your thoughts would be most appreciated.

I would have to look more closely at the code (right now I am away  
from my computer), but I would think the way to do it would be to  
have the OBR bundle export org.apache.felix.bundlerepository.util  
(perhaps we should also change the OBR package to be  
org.apache.felix.obr while we are at it), which contained the class  
that you needed. If necessary we could move around other pieces of  
the OBR impl into that package as well.

The main change I see from the previous thread is now the framework  
is actually using capabilities/requirements internally too. I think I  
slightly modified the original OBR interfaces, though, but we can  
probably deal with that by extending the original interface  
definitions. Regardless, this means that it may now be possible to  
use ManifestParser to convert manifests to capabilities/ 
requirements...or at least it will be in the future. So, we have an  
option now of using the existing OBR approach or adopting the  
ManifestParser if it will be sufficient (or moving in that direction  
later if need be).

As far as pulling the needed bits out and putting them into an OBR  
bundle, that doesn't seem like it should be an issue since maven- 
bundle-plugin can let us pull out specifically what we need and put  
it in the bundle, I would imagine.

The only other issue, might be refactoring some of the names of the  
classes, since R4Directive, etc. aren't really great names since they  
weren't intended to be exposed.

-> richard
View raw message