Re: [crypto] Logging dependency

I'd be a little worried about switching to log4j 2. Two of the main targets of this library when it was proposed were Spark and Hadoop, both of which do not use log4j 2; you might be able to configure them too, but Spark at least has functionality built on top of log4j 1.2, and I'm not sure how

Re: [crypto] On Java 6, really?

I thought there was a discussion after the project was set up to move to Java 7? That being said I see that the pom still defines 1.6 as the target... On Mon, Jun 6, 2016 at 7:18 PM, Gary Gregory wrote: > Are we really starting a new component on a dead platform like

Re: [VOTE] Release CRYPTO 1.0.0 based on RC1

+1 Verified signatures and checksums, all ok. Builds and passes unit tests locally after installing the unlimited strength policy files. On Mon, Jul 25, 2016 at 8:25 PM, Sun, Dapeng wrote: > Hi all, > > > > Apache Commons CRYPTO was established at May 9, 2016, There are

Re: [CRYPTO]1.0.0 Release Plan

On Mon, Jul 11, 2016 at 2:34 AM, sebb wrote: > However bundling multiple native binaries is going to make it tricky to > release. > How will it be done? The native parts will have to be built separately > and then combined somehow. The way I'd do it is to have separate

Re: [CRYPTO]1.0.0 Release Plan

Answering based on old knowledge of this code, but I don't believe it has changed... On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory wrote: > The delivered jar file contains a native .so file, and this .so file is > _extracted_ and _installed_ on the user's machine at

Re: [CRYPTO]1.0.0 Release Plan

On Fri, Jul 8, 2016 at 10:56 AM, Gary Gregory wrote: > On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul > wrote: >> One option could be to go the Eclipse way, the way they handle SWT >> distributions which have native components[1]. >> > Yeah,

Re: [CRYPTO] Drop support for Java 7?

r it fails when trying to execute 'make'. > > I don't know if make is available on those boxes. > Needs further investigation. > > On Fri, 28 Sep 2018 at 11:27, sebb wrote: > > > > On Fri, 28 Sep 2018 at 02:24, Marcelo Vanzin > > wrote: > > > > > &g

[CRYPTO] Drop support for Java 7?

Any concerns with dropping support for Java 7 in the next release of commons-crypto? Are there any rules about not doing that kind of thing in a "minor" release? I was trying to fix up the Travis builds to work on JDK7 but it seems that Travis's support for JDK7 is kinda broken at the moment...

Re: [CRYPTO] Drop support for Java 7?

for those - but I don't think I'll have time to play with that at the moment.) On Thu, Sep 27, 2018 at 10:25 AM Gary Gregory wrote: > > +1 to update to Java 8. > > Gary > > On Thu, Sep 27, 2018 at 11:02 AM Marcelo Vanzin > wrote: > > > Any concerns with dropping

Re: [crypto] Updated to Support OpenSSL 1.1.0i

Hi Alex, There have been other attempts at this (e.g. https://github.com/apache/commons-crypto/pull/90), and my main concern with those is that they require different builds for OpenSSL 1.0 and 1.1. It seems your approach falls in that bucket, at least without additional work. The problem with

Re: [VOTE] Redirect github notifications to issues@

FYI, it should all be done now, so if you want to get notifications, either sign up to issues@, or watch the repo on github. On Fri, Feb 22, 2019 at 9:49 AM Marcelo Vanzin wrote: > > Jira link: https://issues.apache.org/jira/browse/INFRA-17892 > > On Fri, Feb 22, 2019 at 9:44 AM Ma

Re: Github notification and Jira Issues (was: Re: [VOTE] Redirect github notifications to issues@)

On Wed, Feb 20, 2019 at 11:13 AM Pascal Schumacher wrote: > Am 20.02.2019 um 19:39 schrieb Marcelo Vanzin: > > Rob: > >> I almost think that we should have Pull Requests generate jiras. > > I've seen this set up in a couple of projects and jira becomes > > unrea

Re: [VOTE] Redirect github notifications to issues@

On Wed, Feb 20, 2019 at 5:41 AM Gary Gregory wrote: > Is this a LAZY VOTE? Sorry, but not familiar with the semantics of when to call a lazy vs. non-lazy vote. Given the current number of votes, does it matter? Rob: > I almost think that we should have Pull Requests generate jiras. I've seen

Re: [VOTE] Redirect github notifications to issues@

Thanks all, vote passes with 11 +1s, no -1s. I'll file the INFRA ticket and link it back here soon. On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin wrote: > > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So pl

Re: [VOTE] Redirect github notifications to issues@

Jira link: https://issues.apache.org/jira/browse/INFRA-17892 On Fri, Feb 22, 2019 at 9:44 AM Marcelo Vanzin wrote: > > Thanks all, vote passes with 11 +1s, no -1s. > > I'll file the INFRA ticket and link it back here soon. > > On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin

Re: Multiplicity of GitBox messages

I agree it would be best to have people watch the repos they're interested in. If no one objects, I'll open an infra ticket to remove dev@ from commons-crypto updates. (Will leave it to others to update other repos.) On Fri, Feb 8, 2019 at 1:57 PM Eric Barnhill wrote: > > Is it the consensus

Re: [OT][GIT help] How to restore a branch in a github fork

On Tue, Feb 12, 2019 at 5:03 PM sebb wrote: > > Interesting, never seen that. Even just looked at one of my forks and > > couldn't find it... > > It appears when I click on branches. > This shows Overview/Yours/Active/Stale/All branches Ah, I see. Guess I've never used that view. IMO it doesn't

Re: [OT][GIT help] How to restore a branch in a github fork

On Tue, Feb 12, 2019 at 4:44 PM sebb wrote: > > On Wed, 13 Feb 2019 at 00:31, Marcelo Vanzin > wrote: > > > > On Tue, Feb 12, 2019 at 4:25 PM sebb wrote: > > > It's shown as one of 'my' branches, but I guess I can live with that. > > > > Not su

Re: [OT][GIT help] How to restore a branch in a github fork

On Tue, Feb 12, 2019 at 3:58 PM sebb wrote: > Deleted from local and remote. > But it still exists in the upstream from which the Github repo was forked > > It is still in the upstream source - that is a 3rd party repo > How can I restore it from there? It's easy then: - make sure you have the

Re: [OT][GIT help] How to restore a branch in a github fork

On Tue, Feb 12, 2019 at 4:25 PM sebb wrote: > It's shown as one of 'my' branches, but I guess I can live with that. Not sure what you mean by that? The branches in your fork don't really have any relation to the original repo. They may have the same name and even reference the same commit, but

Re: [OT][GIT help] How to restore a branch in a github fork

If: - you deleted the branch from the remote Just push your local branch to the remote. - you deleted the branch from the local repo only Just checkout the remote branch again. If you had local changes that are not in the remote, continue below. - you deleted the branch from local and it did

Re: Multiplicity of GitBox messages

I checked which mailing lists exist for commons, and it looks like different repos are configured differently. e.g. commons-lang has github updates going to issues@, commons-numbers to notifications@, and a bunch, as we can see, to dev@. As long as it's consistent, I'm ok with anything, although

[DISCUSS] Change github notifications for all commons sub-projects

Hey all, There was a recent thread ([1]) with a brief discussion about the number of github updates that are currently ending up in the dev@ mailing list. Personally I find that a little too noisy (especially since I get 2 e-mails for repos that I'm subscribed to), and it seems others also don't

[VOTE] Redirect github notifications to issues@

I'm opening a vote based on recent discussions about the extra noise generated by github updates going to dev@. So please vote: - +1 to redirect github updates of all commons repos to the issues@ list - -1 to keep things as is If the vote passes, I'll take care of opening an infra ticket

Re: JAPICMP Collections-4.3-RC2 report pdf (Was: Re: [VOTE][RC2] Commons collections 4.3)

On Mon, Jan 28, 2019 at 11:01 AM Rob Tompkins wrote: > Before I vote on the the thread, does adding a method to an interface cause > BC to break? I would think not. All of the clirr errors are merely additions. > Further the JAPICMP report confirms this. Existing classes that implement the

Re: JAPICMP Collections-4.3-RC2 report pdf (Was: Re: [VOTE][RC2] Commons collections 4.3)

On Mon, Jan 28, 2019 at 11:36 AM sebb wrote: > > Haven't looked at the code, but if it's being compiled for java 8, and > > the new methods have a default implementation, then it's fine. clirr > > just complains because it's too old to know about default methods. > > I don't think so. > > I think

Re: JAPICMP Collections-4.3-RC2 report pdf (Was: Re: [VOTE][RC2] Commons collections 4.3)

...Yes. That makes sense. Thanks. Seems like this > release should be a -1 then because we’re breaking BC without a major version > change. Right?? > > -Rob > > > > On Jan 28, 2019, at 2:07 PM, Marcelo Vanzin > > wrote: > > > > On Mon, Jan 28, 2019 at

Re: [crypto] Help Releasing new Commons Crypto

siest way to get a jar with multiple native libraries - setting up cross-compilers would be kind of a pain. Now if the requirement is that the release manager needs to build everything himself, then that makes it a little more complicated. -- Marcelo Vanzin van...@gmail.com &

Re: [crypto] Help Releasing new Commons Crypto

Hi Gary, On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory 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: >

Re: [crypto] Help Releasing new Commons Crypto

(-CCs) Hi Gary, thanks for volunteering to help. If needed I can try helping with the release process (e.g. uploading artifacts), but I don't really have the ability to build anything but the linux64 native lib (maybe the linux32 one if I can find the right packages or docker image). I looked at

Re: [crypto] New Release

> > > [INFO] > > > > > > > > > > > > [ERROR] Failed to execute goal > > > > > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on > > project > > >

Re: [crypto] New Release

t; > > > > > > I never did learn why it was there in the first place, but the > > > broken > > > > > > > > build was originally reported as > > > > > > > > > > > > > > > > https://issues.apache.org/ji

Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC

sense but these days may not. On Fri, Aug 25, 2023 at 6:48 PM Alex Remily wrote: > the current module into different maven modules? Not support both?> > > Agreed. Just to provide some history, when I was working on the 1.1.x > upgrade I was guided by commons committer Marcelo V