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
