Split project into several implementation modules

[schildbach]

I looked at all the current issues, pull requests and most of the forks (on GitHub). I noticed almost all changes deal with native code support. Either they want to get rid of specific native libs (because they cause crashes) or they want to support currently unsupported architectures. One PR even wants to get rid of the Java impl such that only native code can be used.

I think a clean way of handling all these cases would be splitting the project into modules:

• scrypt-api: contains only the interfaces.
• scrypt-impl-java: cointains the Java implementation.
• scrypt-impl-android: contains native impls for relevant Android architectures (these days: arm+intel 32+64bit).
• scrypt-impl-desktop: contains native impls for relevant Desktop OSes (Linux, Windows, MacOS).

Of course variations are possible, for example scrypt-impl-java could stay with scrypt-api, or scrypt-impl-desktop could be split into separate scrypt-impl-linux, scrypt-impl-windows and scrypt-impl-macos modules.

Ideally all the modules are built from source, rather than including binary blobs like today.

The idea is for example an Android app would depend on scrypt-impl-android and get all it needs (but not more).

@wg Would you be ok with this concept? You don't necessarly need to implement it yourself.

[wg]

Hi @schildbach, thanks for the suggestion. I'm not willing to add that much complexity to what is a very simple project though. The pure Java implementation should probably always be present in case the native code can't be loaded, and the library binaries are really just meant as a convenience and not cover every possible platform. Otherwise releasing new versions becomes a big hassle.

[schildbach]

IMHO the added complexity would be worth it, since there are so many issues with the current layout. But of course it's your decision.

[hegjon]

It would also simplify the packaging for Fedora. See https://bugzilla.redhat.com/show_bug.cgi?id=1251689