I'm going to CC the Felix project. I'm sure their perspective will be
very useful.
On Nov 9, 2008, at 7:57 AM, Graham Leggett wrote:
Alan D. Cabrera wrote:
You bring up a good point in that it might be a good idea to
describe the target deployments. I'm sure that the APR team lives
in a different universe than I. You probably have to make sure
that the code is general enough to run on my son's bluetooth
enabled talking giraffe as well as stock Linux and Windows Vista
boxes. I'm sure the combinatorial space that you guys have to deal
with is boggling.
I think in this case, my case, we only need to worry about a few
stock configurations, e.g. Linux and Windows. For me that would
handle 99.9% of my universe. More exotic configurations can use
the naming conventions that we are currently working out and
publish on an as needed basis; I don't anticipate this happening
often.
To give some more color to what I want to do, I want to make OSGi
bundles for APR. For example, I need access to raw network
sockets. I don't want downstream users of my bundles to have to
stitch by hand build runtime libraries to get my stuff to work. In
my narrow world it's inconvenient and, I believe, unnecessary.
Hmmm...
I think there are potentially two scenarios to be considered, the
first where a system installed APR is already present, and the
second is where APR is either not present at all, or not the version
you want to run.
Potentially what might work is to have versions of APR that are
statically built, and then bundled into OSGi. Being static, there
would be few/no dependencies on the underlying system.
Another option is to include a stub bundle that refers to a system
installed copy of APR. The stub bundle might be smart enough to
detect when the system copy of APR is either missing, or not within
the tolerated version range.
I think that there's something to be said about using the libraries
that are bundled into OSGi rather than using libraries whose
provenance is unknown.
Regards,
Alan
