Add support for solaris native libraries

[jerrydlamme]

I am adding support for native library build on solaris:
-- sunos32 on x86
-- sunos64 on amd64
-- sunos64 on sparcv9
I am not adding sparc32 lib, since 32-bit Solaris JNI is actually EOL, plus there is a bug for JNI code on sparc32.

Some questions to discuss:

1. I have my changes tested on leveldbjni release 1.8 and it works well.
   I am not able to test it on the current SNAPSHOT version due to this issue I posted:
   Build fails on Linux 64 #57
   Could you help with this issue?
2. Since solaris runs on different processors, I have a new loading path for hawtjni-runtime updated.
   Please see:
   Added architecture specific native library loading path hawtjni#19
   With dependency version for hawtjni updated in the next release, the test cases should pass and
   build should succeed.
   How does this look?
3. I updated the osgi bundle for leveldbjni-all. I am assuming the next release will show up in
   maven's central repository also.
   If you don't have solaris or sparc machines available, we can offer the built leveldb and jni native
   libraries binaries.
   But I am not clear how the releases work?

Thanks for help.
Please let me know any comments for this pull request.

[chirino]

Sounds good. Look like we need to spin a new hawtjni release soon. Thanks for the patch!

[maxd]

@chirino Which version of LevelDB will be provide in new release? Your modified version of LevelDB is totally outdated.

[chirino]

Feel free to send in a PR that merges in the latest changes in leveldb.

[jerrydlamme]

I can try to send an PR for merging the last chagnes in leveldb.

Do you need us to provide the built libleveldb.a or libleveldbjni.so on solaris for the bundle in new release?

[chirino]

Yes. I do the release build in parts. I release the non-platform specific jar first. Then I release each platform specific module. Finally I release the -all module which packages them all together. If you guys would release the solaris platforms, that would be grand!

[chirino]

Tricky bit might be how to pull in from your maven repos.

[jerrydlamme]

This is a problem.
What else way you would prefer for delivering the bits to you?

[jerrydlamme]

One more problem is the
#57
I posted for the current snapshot version.

[chirino]

Another way we could work around this issue is you move the solaris bits into a separate build project with a different group id (one your org controls) and just publish the solaris artifacts under that.

You could even create your own version of the -all jar which includes everything this project's -all has but also adds the solaris bits.

[jerrydlamme]

Thanks.
This makes sense.
Are saying we could back port the solaris bits to release 1.8?
Since the -all only have all the native libs for 1.8 from maven central repo.
(Plus I cannot build on current snapshot version due to that issue, any comment on it?)

[jerrydlamme]

I thought about releasing it under our org. But we don't really want there to be 2 different pacakges for leveldbjni. We would prefer it under your project :)

Is there a way that I can work with you to package the solaris bits under your release??

I think we have options:

We can offer you access to Solaris system for x86 and sparc if you would like to build and release them. I think this is the best option.
OR
We can send you the built solaris bits (for a new release or back port to 1.8?)

Thanks for help

[chirino]

For us to put it under our org, it would need to be released by us but we don't really have those solaris boxes. So it's best if you guys release it. We could just aggregate it in a subsequent release in the -all jar.

[jerrydlamme]

Solaris box is not a problem!
We can offer you access to the Solaris machines.

I will also see if I can get a groupId and do a release for solaris bits