On Wed, 15 Jun 2022 at 01:20, Alex Remily <alex.rem...@gmail.com> wrote: > > 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.
Agreed, but that would still work if the user had to download the appropriate OS version first. > 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. I'm not convinced. I think we would only have to release 2 versions: - macOS plus any Linux versions - Windows plus any Linux versions > 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. Are you saying that the Dockerfile allows any developer to generate the build? e.g. I have macOs but not Windows, so can I use Docker to build the release to support Windows? > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
