Should Lucene4c depend on APR?

[Garrett Rooney <ro...@electricjellyfish.net>]

Currently, Lucene4c makes extremely limited use of APR.

It's basically used for a very small amount of memory allocation (which 
we could do without due to GCJ's garbage collection), and to let us 
integrate with APR pools, for cleanup purposes.

Additionally, we seem to require the use of jlibtool, rather than GNU 
libtool, which means we need APR because that's where jlibtool comes 
from.  This is debatably more of a bug in our build system than a 
dependency though, and we should probably fix it.

So the question becomes, do we want to continue requiring APR, which 
adds a non-trivial dependency, just so that we can integrate with pools? 
  The pool integration could probably be handled just as well with the 
addition of a few wrapper functions, so it's debatable if it needs to be 
handled in the core system.

The other potential reason for keeping APR is that it leaves us the 
ability to retain an API that could actually be implemented in pure C, 
without requiring a GC.  If someone actually picks up the C 
implementation someday and wants to finish it, it would be nice to be 
able to use the same interface we use for the GCJ backed version, and if 
we start to depend totally on the GC without leaving APR pools in the 
picture to provide an alternative we'd be painting ourselves into a 
corner so to speak.

So what do people think?

-garrett