You can run Windows in a VM on macOS, but that’s starting to sound fairly complicated if macOS is itself in a VM.
— Matt Sicker > On Jun 15, 2022, at 18:03, sebb <seb...@gmail.com> wrote: > > On Wed, 15 Jun 2022 at 17:32, Matt Sicker <boa...@gmail.com> wrote: >> >> 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). > > But unless one can host macOS on Windows or vice-versa, AFAICT it will > still require two hosts to generate a release. > >> — >> 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 >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
