Oleg Nenashev
11/06/2024, 10:15 AMSlackbot
11/06/2024, 10:22 AMSlackbot
11/06/2024, 4:26 PMDonát Csikós
11/07/2024, 12:40 PMDonát Csikós
11/07/2024, 12:41 PMDonát Csikós
11/07/2024, 12:43 PMArthur McGibbon
11/07/2024, 1:25 PMArthur McGibbon
11/07/2024, 1:32 PMgradlew clean classes
were re-shown on subsequent gradlew classes
even when no code has changed. This matters more when there are many subprojects and changing one and recompiling means that all warnings associated with the unchanged projects are lost until clean
or --rerun-tasks
is used.Javi
12/11/2024, 12:18 PMJavi
01/07/2025, 3:13 PMritesh singh
02/28/2025, 2:08 PMChAoS - UnItY
03/05/2025, 10:10 AMChisom Chigoziri
03/24/2025, 9:30 AMVanessa Johnson
03/25/2025, 12:28 PMOleg Nenashev
05/16/2025, 7:57 PMOleg Nenashev
05/27/2025, 12:37 PMIvan CLOVIS Canet
06/04/2025, 3:27 PMTooling API clients can access detailed problem reports associated with build failures via theHowever, this only applies to those using the Tooling API, whereas my project would be a Gradle plugin itself. How can I access the reported problems from a Gradle plugin? For convenience (to avoid having it to be declared in each project), it would be better if I could access the reported problems directly from a settings plugin.object on the root build operation. To receive these reports, the clients must register a progress listener for theFailure
operation type. The progress listener callback should then check if the operation result is of typeOperationType.ROOT
, and then it can access the associated problems viaFailureResult
.Failure.getProblems()
Vanessa Johnson
06/10/2025, 10:35 AMVanessa Johnson
07/01/2025, 2:42 AMOleg Nenashev
07/01/2025, 12:42 PMOleg Nenashev
07/08/2025, 10:06 AMOleg Nenashev
07/08/2025, 10:07 AMVanessa Johnson
07/11/2025, 2:03 PMOleg Nenashev
07/15/2025, 11:50 AM