Le mar. 14 juin 2022 à 16:38, Alex Remily <alex.rem...@gmail.com> a écrit : > > As a user and past contributor, my view of Commons Crypto is that it is a > Java wrapper around certain common features of OpenSSL, full stop.
Maybe the mistake was in the name (?). > As > such, it provides near-native performance to the Java developer for > processor-intensive operations via a Java API. It is a set of tools for > developing cryptographic applications in Java only to the extent that it > exposes underlying OpenSSL functionality. The latest contribution offer > seems consistent with that scope because it relates specifically to > functionality that currently exists in the underlying native library. IMO, this description more clearly delineates the scope than what is currently on the web site.[1] > I don't have a strong opinion as to whether the project should be converted > to multi-module, but I'm unclear as to whether or not it would confer any > additional benefit. The existing project structure already separates the > native source from the Java source, and the maven build process already > compiles and packages the native and Java source and binaries > appropriately. There is a Docker file currently in the repository, used > for the 1.1 release, that manages the cross-compilation for the JNI > libraries >From recent conversation, the build process didn't look very smooth, and ultra-fragile given the few people (1 ?) who feel comfortable managing it. > and packages them into the commons-crypto jar. See also my other post, about the possible (?) security implications. Regards, Gilles [1] https://commons.apache.org/proper/commons-crypto > Anyway, that's my $0.02. > > Alex > > 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
