On Feb 6, 2007, at 7:18 PM, Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> 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
