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
