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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
