From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

I’m thinking of issues like <https://github.com/gradle/gradle/issues/1015>. It’s been open for 5+ years. At submission a Gradle employee remarked:
&gt; Thanks for the good bug report. I imagine we’ll tackle this in the not-too-distant future as we continue to improve the speed and correctness of incremental builds.
This is still open and it can be a pretty huge gotcha the first time you hit it, and then every subsequent time that you forget this doesn’t work properly.

polishing existing features is a big part of our focus

the problem with GitHub issues is that there are so many of them :slightly_smiling_face: (almost 2000)

is there a separate internal system for prioritizing/tracking bugs then?

we do have an internal system for tracking larger initiatives and the outcomes are now exposed via the public roadmap

we also take into account the publicly reported issues, for example to identify problematic areas and top-voted issues

and we have a dedicated team responsible for triaging all incoming issues

we are working towards making configuration cache stable later this year but many teams us it in production already with great impact

I'm not sure about project accessors, <@UAB9WQKJ4> do you know?

Unfortunately, I doubt so. Our capacity is limited now. I'll ask.

So, the short answer is still "no". Public APIs should not be changed from Java for multiple reasons. As for internal source code, a decision is required. So, we would not accept PRs for that until the decision is made

First of all, the error <https://github.com/openjdk/jdk/blob/0b0e064e36082200ace384c92eae02d3f7baa7ba/src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java#L229-L232|comes from the JDK’s class reader>

So as far as I understand, the error reporting is pretty weak when the Gradle daemon tries to load a class with a version higher than the currently used daemon JVM.

If that’s the case… good question, probably we are going to receive the said `IllegalArgumentException` when trying to load the external classes, so we would have a chance to emit something better.

cc. <@U04GRRRT8QN> WDYT?

We could dig into it.
This in particular seems to come from Groovy (The “BUG! ” gives it away I think.)
So it seems Groovy is complaining about a too new version of the JDK.
There is probably some chance to intercept the Exception and handle it in a less generic way.
I think we should have an issue for it and prioritize it through the prober channels.

<@UJQ5BC4BF> Thanks for the suggestion, and sorry for the late reply. Could you clarify what you mean by
&gt; Comments here would be disconnected from the issues themselves, and can't be subscribed to on a per-issue basis.

Ah, I guess you mean the comments here in this Slack are disconnected from the issues

We intentionally disabled comments on the roadmap board as it can be quite noisy for those who just want to subscribe for major updates and status changes for the issues there

We currently recommend discussing here or on our Forums

We could consider enabling <https://docs.github.com/en/discussions>. WDYT?

Why do you think Gradle does not support JUnit parallelization? Assuming you mean the Jupiter built-in parallelization. Just enable it and it will work, Gradle is not involved in that, it just tells JUnit platform "do your thing" and JUnit plaform will then tell Jupiter "do your thing" and Jupiter decides how it runs the tests.

We were having trouble with the outputs and test results when we enabled the JUnit built-in parallelization. This is one of the SO discussions I found on the matter: <https://stackoverflow.com/questions/63346743/junit-5-parallel-test-execution-loses-output-from-tests>

Well, capturing stdout / stderr per test can of course be problematic if this is done by Gradle. If you run 5 tests in parallel, how should Gradle know which test was outputting what.

Ah, seems JUnit platform has some facililty for mitigating that problem. Issue that tracks the problem is <https://github.com/gradle/gradle/issues/16270>

Thanks! I found this one as well just now: <https://github.com/gradle/gradle/issues/4605>

Going back to the original question, is this something that'd earn its spot on the roadmap? I'm not necessarily pushing for it, mostly just evaluating our options :slightly_smiling_face:

I didn't try, as I was not aware of this problem up to now.
But if you use the setting that is mentioned in the JUnit 5 docs that are linked in the issue I posted, I assume that the output will only be in those mentioned properties and not actually printed.
If you then add an own `TestExecutionListener` that outputs those properties to stdout and stderr, maybe Gradle is able to pick it up properly?

(I cannot say anything to the roadmap, I'm not affiliated to Gradle)

The thing is, without support for the reporting entries, we can't get the output through to IDEA as far as I understand it. When I run JUnit from IDEA directly, it correctly shows the report entries per-test, so it's easy to navigate them. Implementing the `TestExecutionListener`  to just "print" the values, would not associate them with the tests, so it's better, but not a ton better than the current behavior

Did you try? I would assume is also works in IntelliJ as expected. But as I said, just guessing here. :slightly_smiling_face:

How would Gradle know which test produced the output just from stdout?

The JUnit docs say, that these properties with stdout and stderr are emitted right before the test finished event, so it could then probably just get it by that. There is of course still potential for errors / race conditions.

Actually, you could maybe somehow determine that the test is run from IntelliJ directly and not via Gradle delegation and then not do it. Maybe IntelliJ sets some system property like it does when it runs Gradle tasks, or if not maybe you can check whether some IntelliJ test execution listener is registered if you can query them. :man-shrugging:

If that was the case, just printing at the end of a test would work, but it doesn't.

IntelliJ registers it's own `TestExecutionListener` as far as I know and therefore receives the entries from the `TestReporter`

But since Gradle doesn't support it, there's no way for IDEA to do the same when running tests through Gradle. We can't really run tests through IDEA, we need to run them through Gradle, so it doesn't seem workaroundable

Are you sure IntelliJ adds an own `TestExecutionListener` when running the tests through Gradle?

No, when IntelliJ runs tests through Gradle, it can't add it's own `TestExecutionListener`, that's why it doesn't work when going through Gradle

I'd love to see <https://github.com/gradle/gradle/issues/17101|Introduce a way to visit every external dependency #17101> make the roadmap.

I understand it couldn't be bulletproof (it would require using well behaved plugins that declare all their dependencies in a way Gradle can interrogate without running the tasks), but even with that limitation I think my use cases in <https://github.com/gradle/gradle/issues/17101#issuecomment-1628818695|my comment> are genuinely useful.

Sometimes it is extremely unclear for an outsider (or at least to me) to get what a roadmap item means.
For example <https://github.com/gradle/build-tool-roadmap/issues/79>

Such items are really difficult for an insider too, even for a common issue

For those who're interested about Gradle's roadmap for Gradle 9 <https://blog.gradle.org/road-to-gradle-9>

Pretty sure <https://github.com/gradle/build-tool-roadmap/issues/88|this> task was incorrectly marked as completed. Gradle 8.11 only included parallel load/store of CC entries unless I'm mistaken.

Linking here in case it gets more visibility <https://gradle-community.slack.com/archives/CAHSN3LDN/p1747407377265309>

Is Eclipse Buildship and the Gradle support in VSCode/Eclipse considered roadmap worthy? Whats the current position of Gradle on IDE support?

Hi <@UBA11MM6Y> Just a quick answer, we are interested in supporting all popular IDEs, and has been no change in this direction though ofc particular projects are a subject for prioritization.

As you can see on the public roadmap, currently the team focuses on Problems API and better reporting for errors and warnings - <https://github.com/gradle/build-tool-roadmap/issues/49> . It is a foundation work needed for many IDE and CI/CD integrations

There has been also work on prototyping IDE integrations for Declarative Gradle, and on enabling the Provider API Migration towards Gradle 9.


Hopefully it summarizes the current state. CCing <@UCUP8E78U> and <@U04GRRRT8QN> from the UX team that currently focuses on integrations.

What's the status of roadmap item #54, finally promoting JVM Test Suites?
It was originally planned to be done in Q3 2023, but was moved and moved and now is in "Backlog".
What is missing for it, are there plans that the current API will change, or are there other reasons not to promote it yet?

Several of us got pulled into something else.

There are several things we wanted to investigate that we thought would impact the implementation/design.

• We wanted to de-incubate the `dependencies {}` block (this has mostly happened except for some version catalog related APIs).
• We wanted to make testing frameworks extensible, so there wasn't dozens of methods on `JvmTestSuite` to enable different testing frameworks. We made some internal changes to prepare for this but did not finish.
• We wanted to support multiple test targets per suite. Questions around how this would work with test aggregation were blocked until ~Dec last year. 
• We wanted to use test suites to dogfood multi-variant libraries (compiling sources multiple times or at least compiling prod/test differently).
In general, I think the structure/shape of it will not change. The `dependencies {}` block isn't going to change. The `useJUnitJupiter(...)` APIs may change, but I think we'd deprecate what we have now. I'd like to add more configurable options to the test target so you don't have to touch the task anymore.

Ok, thank you very much for the details.
Sounds like it will need quite some more work and time to be promoted. :-)