apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Apache Portable Runtime artifacts
Date Sun, 09 Nov 2008 15:57:35 GMT
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.


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.


View raw message