Currently, all a user needs to do to use commons-crypto is to include it as a dependency in an application that runs on a supported operating system with a supported version of OpenSSL (1.0 and 1.1). Commons-crypto dynamically, and IMO quite elegantly, determines the underlying OS and OpenSSL version and calls the correct corresponding JNI library and OpenSSL API. It can do this because it packages JNI libraries for all supported operating systems with the distribution and it performs runtime version checks of OpenSSL. It *is* easier to perform a single-platform build, but that would require us to release a separate build for every supported OS, which I would argue is more complex than releasing one build for all supported operating systems. Also, the heavy lifting of supporting a multi-OS build has already been done via the existing Dockerfile. I don't see any reason to move away from the current release strategy.
On Tue, Jun 14, 2022 at 6:51 PM sebb <seb...@gmail.com> wrote: > On Tue, 14 Jun 2022 at 16:26, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > Hi All, > > > > The component name was indeed ill chosen for what is effectively an > > OpenSSL wrapper. Maybe we could make that obvious on the site by > > calling the page "Apache Commons Crypto, an OpenSSL wrapper". > > > > I am in favor of adding more Java methods to wrap more OpenSSL APIs as > > PR #165 does, that seems like a natural fit. > > > > I do not see the need to convert this component into a multi-module > > Maven project. Keep it simple IMO. > > However, it might make it easier to release the binaries if they were > packaged separately, one per OS. > > > Gary > > https://github.com/apache/commons-crypto/pull/165 > > > > On Tue, Jun 14, 2022 at 9:10 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > > Hello. > > > > > > Contradicting comments about the latest contribution offer[1] suggest > > > that the scope of the [Crypto] component is ill-defined. > > > > > > Is it a Java wrapper around a specific library ("openssl")? > > > Is it a set of tools (a.o. strong random number generators) for > developing > > > cryptographic applications in Java? > > > Is it both? Does it intend to be more? > > > > > > In order to simplify maintenance (and clarify expectations), shouldn't > it > > > become a (maven) multi-module project, with explicit separation between > > > platform-agnostic functionality and platform-specific (native) codes? > > > > > > Regards, > > > Gilles > > > > > > [1] https://issues.apache.org/jira/browse/CRYPTO-162 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
