Just submitted a PR to increase the coverage in the streams package. While prepping the PR I noticed the Travis Mac build is testing against LibreSSL, which doesn't successfully load the native libraries to support JNI:
[WARNING] Tests run: 139, Failures: 0, Errors: 0, Skipped: 42 Note the 42 tests that are skipped. 40 of these tests are skipped because commons-crypto couldn't find the native library to run the JNI test. If possible, I'd recommend configuring the Travis Mac build with OpenSSL proper, not LibreSSL. I'd prefer not to support any derivative distribution. On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake <geoffrey.w.bl...@gmail.com> wrote: > > I figure everyone is a bit busy, but wanted to ask where we are all in > getting close to a new release of commons-crypto that contains the new > binaries, Alex, Gary? Any other unit test areas that need attention > Alex that you may need help with? > > -Geoff > > On Wed, Apr 22, 2020 at 11:33 AM Adam Retter > <adam.ret...@googlemail.com.invalid> wrote: > > > > If you want to build on CentOS for releases that is fine - I can add > > Docker Build Environments as a Travis job that use older CentOS. > > > > On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake <geoffrey.w.bl...@gmail.com> > > wrote: > > > > > > I think it depends on whether using Ubuntu 14.04/16.04 as the base > > > distro for releases is ok. It seems most projects like to build on > > > some variant of RHEL/CentOS as they typically use stable (read older) > > > compilers and libc. > > > > > > Does Travis allow building all the binaries then having a final > > > process that gathers all the artifacts up in the end to perform the > > > release? > > > > > > @garydgregory, thoughts on this? > > > > > > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter > > > <adam.ret...@googlemail.com.invalid> wrote: > > > > > > > > No that https://github.com/apache/commons-crypto/pull/96 has been > > > > merged, we have support for Arm64, ppc64le and x64 in Travis. > > > > > > > > I wondered if it was useful for the "Release Process" if we had Travis > > > > build and store release artifacts? I believe we can have Travis do > > > > this only when Git tags are created. So if there is a Tag for each > > > > release (which I assume there is) - then you could have the release > > > > binaries built and delivered automatically for you. It is possible to > > > > go as far as having them uploaded to Maven Central (staging) if you > > > > wished. > > > > > > > > On Sat, 18 Apr 2020 at 17:40, Adam Retter <adam.ret...@googlemail.com> > > > > wrote: > > > > > > > > > > As promised, I added support for further environments to Travis - > > > > > https://github.com/apache/commons-crypto/pull/96 > > > > > > > > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily <alex.rem...@gmail.com> > > > > > wrote: > > > > > > > > > > > > I don't know whether it would help the build manager with the > > > > > > release > > > > > > process, but I think it would be a good idea to update the build > > > > > > matrix > > > > > > regardless. I made an attempt a while ago to add coverage for more > > > > > > environments, but ultimately I wasn't successful. I don't recall > > > > > > if the > > > > > > limitations were Travis's or my own, but I would certainly welcome > > > > > > someone > > > > > > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 > > > > > > APIs in > > > > > > whatever Windows, Mac, Linux and Arm64 environments Travis > > > > > > supports. My > > > > > > $0.02. > > > > > > > > > > > > Alex > > > > > > > > > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter > > > > > > <adam.ret...@googlemail.com.invalid> wrote: > > > > > > > > > > > > > Travis now offer Arm64 and Mac. I could setup a job to build > > > > > > > binaries on > > > > > > > Travis and keep a copy either on every commit or when a tag is > > > > > > > created. > > > > > > > Would that be helpful? > > > > > > > > > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, <garydgreg...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily > > > > > > > > <alex.rem...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm > > > > > > > > > happy to > > > > > > > > > provide whichever of those is required. It seems that Geoff > > > > > > > > > can do the > > > > > > > > > arm64 build. Do we even bother supporting 32 bit > > > > > > > > > architectures at this > > > > > > > > > point? > > > > > > > > > > > > > > > > > > > > > > > > > Unfortunately, we cannot just pick up bits from folks here and > > > > > > > > there. It > > > > > > > > all has to be buildable from Maven by the release manager in > > > > > > > > order to > > > > > > > > generate the file signatures properly. > > > > > > > > > > > > > > > > Based on what I see in the docs, it looks like this is > > > > > > > > buildable using > > > > > > > > cross-compilation with MinGW on Windows. Not sure about the Mac > > > > > > > > stuff > > > > > > > yet. > > > > > > > > > > > > > > > > I'm not sure what the use-case is for 32-bit at this point. > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin > > > > > > > > > <van...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory > > > > > > > > > > <garydgreg...@gmail.com > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > The 1.0 release on maven central only included linux32 > > > > > > > > > > > > and > > > > > > > linux64 > > > > > > > > > > native > > > > > > > > > > > > libs, even though the Makefile supports many more > > > > > > > > > > > > targets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see the snapshot builds which now include more: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT > > > > > > > > > > > > > > > > > > > > Here's the native stuff in your snapshot jar: > > > > > > > > > > > > > > > > > > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep > > > > > > > > > > nativeorg/apache/commons/crypto/native/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > > > > > > > > > > > > > > Here's the 1.0 release: > > > > > > > > > > > > > > > > > > > > $ jar tf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar > > > > > > > > > > | grep native > > > > > > > > > > org/apache/commons/crypto/native/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ > > > > > > > > > > org/apache/commons/crypto/native/Mac/ > > > > > > > > > > org/apache/commons/crypto/native/Mac/x86_64/ > > > > > > > > > > org/apache/commons/crypto/native/Windows/ > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86/ > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86_64/ > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so > > > > > > > > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > > > > > > > > > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll > > > > > > > > > > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll > > > > > > > > > > > > > > > > > > > > That's the only thing that worries me: finding someone who > > > > > > > > > > can build > > > > > > > > > > all those extra native libraries. I tend to agree that > > > > > > > > > > linux64 is the > > > > > > > > > > most important one, but it would be technically a > > > > > > > > > > regression from 1.0 > > > > > > > > > > to skip the others. > > > > > > > > > > > > > > > > > > > > That being said, if we can't solve that, I think it's > > > > > > > > > > better to > > > > > > > > > > release something rather than nothing. > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Adam Retter > > > > > > > > > > skype: adam.retter > > > > > tweet: adamretter > > > > > http://www.adamretter.org.uk > > > > > > > > > > > > > > > > -- > > > > Adam Retter > > > > > > > > skype: adam.retter > > > > tweet: adamretter > > > > http://www.adamretter.org.uk > > > > > > > > --------------------------------------------------------------------- > > > > 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 > > > > > > > > > -- > > Adam Retter > > > > skype: adam.retter > > tweet: adamretter > > http://www.adamretter.org.uk > > > > --------------------------------------------------------------------- > > 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
