On Nov 9, 2008, at 4:31 AM, Graham Leggett wrote:
Alan D. Cabrera wrote:
I was thinking that the artifact name could be
apr-<osname>-<processor>
e.g. apr-linux-x86_64. Or we can have a more general
apr-<osname>-<processor>-<configuration>
where configuration is a token that represents a particular
configuration of options, e.g. apr-msdos-8086-aztecc.
I don't use the apr-util code. Can you explain what extra
dependencies there are?
APR is typically installed at the system level, as a JVM would be,
and being installed at a system level it would have a number of
system dependencies installed along with it, some of which are
optional.
In order to better understand the solution to this, can you explain
the problem you are trying to solve?
Am I correct in assuming that you would like to access APR from Java
(like tomcat does)?
If this is correct, it may make more sense to deploy the JNI
bindings for APR into the maven repo, and then have those bindings
depend on the system installed version of APR.
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.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
