We could always request a Windows VM from Infra if necessary for building releases. Same for a Mac VM or Linux VM, though the Linux one can be done fairly easily via Docker on any OS (even FreeBSD supports Linux containers now).
— Matt Sicker > On Jun 15, 2022, at 05:10, sebb <seb...@gmail.com> wrote: > > 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 >
