I got a test failure (on Java 11):
Execution failed for task ':groovy-testng:test'.
> Dependency verification failed for configuration
':groovy-testng:testRuntimeClasspath'
One artifact failed verification: jcommander-1.78.jar
(com.beust:jcommander:1.78) from repository MavenRepo
This can
Le mar. 13 avr. 2021 à 13:04, Paul King a écrit :
> We don't use the keys file (being binary) for the source build. I guess we
> could offer a way to bootstrap that too like we do for gradlew. Then users
> could choose if they wanted to do the build with or without.
>
To me it feels a bit
Technically it's not Gradle's dependency verification which is flaky, it's
the key servers. That's why you must, from time to time, update the local
keyring, using `--export-keys` as explained in
https://docs.gradle.org/current/userguide/dependency_verification.html#sec:local-keyring
Then the
On Tue, Apr 13, 2021 at 9:51 PM Cédric Champeau
wrote:
>
>
> Le mar. 13 avr. 2021 à 13:04, Paul King a écrit :
>
>> We don't use the keys file (being binary) for the source build. I guess
>> we could offer a way to bootstrap that too like we do for gradlew. Then
>> users could choose if they
Oops, forgot the mailing list.
-- Forwarded message -
From: Paul King
Date: Tue, Apr 13, 2021 at 7:56 PM
Subject: Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3
To: Guillaume Laforge
Gradle's dependency verification (incubating feature) does seem to be a
little flakey
We don't use the keys file (being binary) for the source build. I guess we
could offer a way to bootstrap that too like we do for gradlew. Then users
could choose if they wanted to do the build with or without.
What would be good from the Gradle side is a better way to flush and
restart
I tried to do ./gradlew --write-verification-metadata pgp,sha256
--export-keys
as I can't try the gpg command, as I don't have it installed on my system
it seems.
The build still failed.
I followed Paul's suggestion, and the build worked.
https://scans.gradle.com/s/7dle2o3ieepsw
Also, my manual
Hi Leonard,
It would be great if you could provide a PR to backport these changes.
Thanks in advance!
P.S. sorry for the late reply, too busy recently...
Cheers,
Daniel Sun
On 2021/03/17 20:03:21, Leonard Brünings wrote:
> Hi,
>
> recently Björn Kautler and I worked on a feature to
Hi Folks,
I've created 4.0.0-beta-1 as the next release for Groovy 4 assuming alpha-3
voting goes smoothly. If we decide we need another alpha, we can always
rename that release.
Cheers, Paul.
+1
From: Paul King
Sent: Monday, April 12, 2021 9:57 PM
To: Groovy_Developers
Subject: [VOTE] Release Apache Groovy 4.0.0-alpha-3
Dear development community,
I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-3 release!
This release includes 152 bug fixes/improvements as outlined
10 matches
Mail list logo