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

Gradle Community

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, the message is quite clear, isn't it? Your are running Gradle with a JRE but needed to run it with a JDK for one of the plugins used in that project working properly. Check your `JAVA_HOME` environment variable.

So I got it working (downloading correct jdk release) but then it failed on `languagePredicate()` within `JavaToolchainMatcher` . The reason is that the implementation calls `equals()` on `JavaLanguageVersion` which returns false because I am using my own implementation of that interface. There is nothing I can do about it. Shame.

Just FYI, I managed to get it working with the help of project properties and reading them within the custom resolver (a resolver can not have any parameters). It's not ideal, it's not perfect, but until it is supported by Gradle itself, it is sufficient for our needs.

I filed a support ticket about this also, but I’m asking here in case someone else has any ideas. Thanks!

in a plugin, I'm setting the project group (`target.group = "foo"`). When I do that, I get this error
```* What went wrong:
Circular dependency between the following tasks:
:addons:public:compileJava
+--- :addons:public:compileJava (*)
\--- :addons:public:compileKotlin
     +--- :addons:public:compileJava (*)
     \--- :addons:public:compileKotlin (*)

(*) - details omitted (listed previously)```
if instead I set the group in the `build.gradle`, that error does not occur. Any ideas on why this might happen?

I also don't get the error if I set the group in the `publishing.publications` block :thinking_face:

I've seen seldomly that the up-to-date state got confused and didn't rerun tasks with changed inputs.
I was not able to investigate what causes it or how to targetly fix it.
I just tried to get the colleague back on track quickly.
So delete `.gradle` in the root project and everything in `&lt;GRADLE_USER_HOME&gt;` except things you created manually like `init.d` directory or `gradle.properties`.
Then the up-to-date checks should hopefully work properly again if it is the same issue I've observed occasionally.

Hello, I had similar behaviour in intellij when I was switching between delegating building to gradle and using intellij compiler. Intellij compiler produced class files into `out` folder which idea picked up even when it was already switched to delegate to gradle and was causing picking old compiled classes to be loaded first on the classpath. Solution was deleting the `out` dirs in modules

What I described was a pure Gradle problem though, building from the commandline.

But what you describe sounds like a bug you should report at <http://youtrack.jetbrains.com|youtrack.jetbrains.com> if you didn't already. :-)

Regarding your first question, I know of two issues that you can follow (and vote for :)): <https://github.com/gradle/gradle/issues/9282>, <https://github.com/gradle/gradle/issues/17963>

I'm not sure I understand the second question

&gt; Everything works but getting the dependency notation for the Gradle plugins is annoying.
What is so annoying in using `&lt;plugin id&gt;:&lt;plugin id&gt;.gradle.plugin:&lt;plugin version&gt;`?
Of course it is not super convenient which is why those tickets exist and even a PR that will hopefully fix it.
But it's not *that* bad and you can write a helper function that does it for you easily.

Regarding the repositories, you could refactor out those repository declarations into another included build that you then use from within the `build-logic` plugin and in the settings script of the main build.

Don't know why I not getting notifications.
Regarding getting the fqn of a plugin, thanks for the hint with the plugin id!

I guess this syntax is used when gradle resolves the plugin? Because some plugins use another name, like `gradle.plugin.com.github.johnrengelman:shadow:7.1.2` for `com.github.johnrengelman.shadow`.
Upvoted both issues.

Okay, adding another `includeBuild` just for the repos would be possible, but a little bit overkill for 4 lines. I already use a `Settings` plugin in the `build-logic` like this:
```pluginManagement {
    repositories {
        maven(url = "<https://oss.sonatype.org/content/repositories/snapshots>")
        mavenCentral()
        gradlePluginPortal()
    }
    includeBuild("build-logic")
}

plugins {
    id("MyRepos")
}```
but applying the settings plugin `MyRepos` without adding the repositories still fails.

&gt; Because some plugins use another name, like `gradle.plugin.com.github.johnrengelman:shadow:7.1.2` for `com.github.johnrengelman.shadow`.
Thats the coordinates of the actual code-containing artifact.
Then you have an additional marker artifact for each plugin in that code artifact following that naming pattern, that is used to resolve from plugin id to some artifact, exactly.

&gt; but applying the settings plugin `MyRepos` without adding the repositories still fails.
Yeah, that's hen-and-egg problem of course.
If that settings plugin needs to come from a repo you have to declare the repo first.

Nope, the settings plugin `MyRepos` is declared in `build-logic` too. Otherwise I would totally agree.

Looks like maybe this will work:

```listOfProviders.zipWithNext { a, b -&gt; 
  a.zip(b) { listA, listB -&gt;
    listA + listB
  }
}```

Full solution:

```fun &lt;T&gt; combineProviders(
  providers: List&lt;Provider&lt;List&lt;T&gt;&gt;&gt;
): Provider&lt;List&lt;T&gt;&gt; {
  var p = providers
          
  while(p.size &gt; 1) {
    p = p.zipWithNext { a, b -&gt;
      a.zip(b) { listA, listB -&gt;
        listA + listB
      }
    }
  

  return p.first()
 }```
Now of course someone will point out that there's a Gradle API for this :see_no_evil:

Maybe something like:
```val listProperty = objects.listProperty&lt;T&gt;()
providers.forEach { listProperty.addAll(it) }
return listProperty as Provider&lt;List&lt;T&gt;&gt;```


I'm not sure what your mean. Gradle runs tests where you tell it to. Just having a dependency will not cause any tests to run, as Gradle avoids work wherever it can. Can you maybe provide a more compete MCVE that demonstrates what you mean?

What I see in our repo is that when you build something in Gradle, it _*recursively*_ builds everything defined in the settings.gradle
```include ':observability:bundle'
project(':observability').projectDir = file('../observability')
project(':observability:bundle').projectDir = file('../observability/bundle')```
and defined in build.gradle
```dependencies {

    implementation project(':observability:bundle')
}```
_*Recursively*_ building includes running the `assemble` and `check` tasks... consequently running tests.

This is the behaviour I have always seen in Gradle.

I assumed this was normal as that is similar to the behaviour of Maven.

I am considering simply making observability-bundle a library and pushing it to an artifact repository, decoupling it from `settings.gradle` but was wondering if there was something more simple.

Still not sure what you mean. There is nothing done recursively. If you call the `build` task of the root project like `./gradlew :build`, then only the tests of the root project are executed unless you configure it differently. If you on the other hand do `./gradlew build` you are telling Gradle to run the `build` task in all projects that have it, whether there is a dependency or not is irrelevant.

Yes, we are doing `./gradlew build`

I assure you, it is recursive.

And I assure you it isn't unless you made it. As I just explained, that command runs the `build` task in all projects that have one, as you don't specify which one you want to run explicitly. This is independent from any dependency declarations and there is no recursiveness.

I have been taking Gradle online course, and in the course, he describes the build process as recursive. So, I just have no idea what you are talking about. That seems to be the default behaviour of Gradle.

To put what <@URQ797WRW> is saying a bit differently, there is a major difference between `./gradlew build` and `./gradlew :build`. The former runs the `build` task of every project (not necessarily recursively) while the latter runs `build` only for the root project. It sounds like you're expecting only the `build` task of the root project to run, so you should be using `./gradlew :build`.

As I said, we are doing `./gradlew build` or `./gradlew clean build`

This has more to do with how Gradle is invoked from our build pipeline in GitLab, and the default is `./gradlew clean build`

If you suggest we change that, then I will run it by the team.

What I was originally asking was if I could disable the test be run recursively, but now that I understand the issue better, that was not the right question to ask.

Our team are not at all Gradle experts... so things are not usually done well...

I am trying to become the Gradle expert... and still learning.

&gt; Our team are not at all Gradle experts... so things are not usually done well...
Understood. I think you've come to the right place for help. :slightly_smiling_face:

&gt; If you suggest we change that, then I will run it by the team.
I am not suggesting anything. I just wanted to see if I could help explain the subtle difference between `./gradlew &lt;task&gt;` and `./gradlew :&lt;task&gt;`.

Is your original question answered? If not, maybe you could restate it?

Thanks, that really clarified things. It is a subtle difference that I can now explain to the rest of the team.

My original question is moot as I understand better what is going on.

Part of my goal in the new year is to learn Gradle well enough to do a significant overhaul of the Big Ball Of Mud we currently have.

This current issue came up when I upgraded a leaf dependency with Gradle 7.6, but other parts of the build are running older versions.

Gradle Wrapper introduces problems I have never encountered in Maven cause there is no Maven Wrapper. I understand how Rah Rah people are about Gradle Wrapper, but it does have problems that no-one wants to admit to.

If you encounter problems with the Gradle wrapper you can always ask here and we can try to help. What issues specifically are you running when using the wrapper?

The worse problem is trying to upgrade Gradle wrapper. It fails to upgrade if the configuration files do not conform to what the new version wants. I did get help from <@UES7RHBDZ> on this, but still the behavior is unexpected and problematic.

&gt; Gradle Wrapper introduces problems I have never encountered in Maven cause there is no Maven Wrapper.
Well, that's not fully correct.
They copied the concept from Gradle like they copied some other concepts.
You don't need to use the wrapper, but imho any project should use it.
Without the wrapper you have the problem you have with Maven, that using different versions of Maven to run the build can produce different results or even break.
While with the wrapper the version of Gradle used to run the build is specified explicitly, so the build behaves reproducibly and well defined. :slightly_smiling_face:

&gt; The worse problem is trying to upgrade Gradle wrapper.
I never had problems with that, and I use Gradle since pre 1.0.
I'm curious, what problems did you have specifically?

&gt; It fails to upgrade if the configuration files do not conform to what the new version wants
Unless I get you wrong, that sounds very unlikely.
If you call the wrapper task, the configuration file is simply overwritten.
And the format didn't change as long as I can remember, just 2 or 3 possible keys added, but nothing incompatible. :confused:

Or do you mean the build scripts when you say "configuration files"?
Those of course have to be compatible with the new version, that seems logical. :smile:

The second problem with Gradle is people telling me
&gt; I never had problems with that


The build scripts do have to be valid before performing an upgrade of the wrapper. Though I'd say it is generally a good practice to make sure the build scripts are valid with the current version, then perform the upgrade. If your build scripts are not valid with the current version, upgrading is not going to help.

&gt; The build scripts do have to be valid before performing an upgrade of the wrapper
I should say, to perform an automated wrapper upgrade (e.g. using Gradle). You always have the option of doing a manual upgrade of the wrapper yourself.

&gt; The second problem with Gradle is people telling me
&gt;&gt; I never had problems with that
That's probably more a sign that you need to provide more information or an MCVE, so that your problem can be reproduced. :wink:

To be sure, I understand the purpose of validating the build scripts before upgrading...

However, people fail to realize that Gradle diagnostics are not great, so this becomes frustrating...

Yes, Tony showed me how to force an upgrade to the wrapper, after which it is easier for me to fix any incompatibilities.

<@URQ797WRW> -- why are you always blame-shifting? I know you are trying to be helpful, but mostly you are invalidating.

I'm sorry if you feel like that, English is not my native language, so I'm not always getting things expressed like intended. :disappointed:

Usually if you upgrade to the latest minor version and there fix all deprecation warnings, an upgrade to the next major version should work pretty well, also keeping in mind the upgrade notes in the user guide (that are not included in the release notes, just linked to)
If you try to do bigger upgrade steps, it can easily get frustrating, yes.

Btw. if you are unhappy with what I say or how I say it, just tell me and I'll just stop answering your questions if you prefer.
Would also be fine with me.
As you said, I just try to help, but if I just increase your frustration, it doesn't make any sense of course.

My current project at work is to upgrade the myriad Gradle Wrappers we have to 7.6, which is how this current problem came up wrt to recursive builds.

<@URQ797WRW> I would rather you learn how to communicate more effectively so that are more successful in helping others, in helping everyone. I would be happy to help. However, saying things like
&gt; Btw. if you are unhappy with what I say or how I say it, just tell me and I'll just stop answering your questions if you prefer.
&gt; Would also be fine with me.
is not effective.

Most people I'm trying to help are very happy with what I say and how I say it, so my communication skills cannot be *that* bad.
Of course they are not optimal, noones are, including yours, I'm just not complaining about it.
You cannot make "everyone" happy.
And you have to keep in mind that I'm not a paid Gradle employee.
I'm a user like you, helping other users in my spare time.

Fine <@URQ797WRW>, don't talk to me anymore. You do not seem to be mature enough to want to improve the quality of your communication style. You are stuck forever blaming others.

<@U045HSQL5CH> assuming you're new here and you don't know that <@URQ797WRW> is *the most* helpful member of this group, probably more so than the Gradle employees here (not that it detracts from their helpfulness).

The way you've been talking in this thread is abhorrent, especially since these people owe you nothing, and are trying to help you (despite you not recognizing that).

The only thing you'll accomplish is to not have anyone here offer you help, although there are much nicer people than me (like <@URQ797WRW>) who would likely still go out of their way to help you.

<@U045HSQL5CH> I want to share with you a thought I learned in my first 1-2 months when I started to develop.

It is easy to blame the tool, but 99% of the times, the problem will be the developer, and probably it will be 99.99% of the times if the user is still learning the tool.

Obviously any tool can have bad documentation, outdated snippets, bugs on edge cases, or whatever, and using that can cause you create wrong code, but I am not going to talk about that right now.

The fact is you are sharing a problem with almost the most base use case of this tool, Gradle, with more than a decade running it, and thinking that the tool is failing... it is pretty optimistic. I do that every day on any tool, but... 99% its my bad.

I think it is reasonable that <@URQ797WRW> ask for a minimum repro in order to reproduce it and see what is happening, and thinking that the problem is the user or the information provided in this case is normal for me, as it is not an edge case and everyone is running specific tasks on specific modules without seeing this problem for years.

Another thing, and this is not pointing to what or how <@URQ797WRW> said, just a general thought I have. On open source you will see people trying to help you, with better or worse words, and with cultures and languages totally different to yours, but at the end, trying to help you. It is better to center in the help itself, in the final end, instead of in how it was. Keep getting the good part of the message and learn from it, forget the destructive part of the message.

since folks are piling on, I feel the need to step in (since I was pinged on this thread). In my opinion, it's a really weak excuse to say "English is not my native language, that's why I sound like a jerk" (to paraphrase). Especially weak when coming from someone who is obviously as fluent as Vampire is. Yes the content of the message matters, but to pretend that the method of expression is meaningless is a major failing of people who identify as engineers. Good communication skills are important, and valuable, and this is far from the first time someone has taken umbridge at Vampire's preferred mode of expression.

Note that I am _not_ saying he is unhelpful. He is often quite helpful in this slack. But I think he should do some self-reflection and maybe take a mediation or communications course because he has alienated several people in the time I've been here.

<@U045HSQL5CH> I am really glad you are learning Gradle!
Some resources I recommend
• our in house training <https://gradle-community.slack.com/archives/CAHSN3LDN/p1671215281292459|here> or linked <https://gradle.org/courses/|here>
• Video series by <https://www.youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE|Gradle Fellow Jendrik >
• Blog posts by <https://dev.to/autonomousapps|Gradle Fellow Tony>


<@U021PMD2TL4>, I'm afraid I have to disagree that Vampire is _*the most*_ helpful as, routinely, I find other people more helpful. Sure, he is helpful at times, but I am usually frustrated by his communication style. He is often confusing, whereas others are clear. It takes me 10 times longer to solve a problem via Vampire than via others.

In this conversation, Vampire could not seem to hear what I was saying, and eventually, <@U042816HVD0> clarified the conversation more directly.

<@UES7RHBDZ> is consistently clearer in his communications, so I value them much more highly. <@U042816HVD0> is clearly a better communicator too. _Vampire is not a good communicator,_ and I even offered to help him improve. He was the one who immaturely got snarky and offered to not talk to me anymore. Vampire's problem is not ESL; it is the basic communication ability. At work, I often review the written work of ESL colleagues to help them improve. When I was young, even though English was my first language, my writing was poor, but dedicated colleagues kept helping me improve. I never took it as negative criticism, I gratefully took it as constructive criticism.

Over the course of my career, people frequently say things like, "Well, it works for me." "Well, I have no problem." These are incredibly invalidating statements that tend to come from a particular type of person who has self-esteem issues. People without self-esteem issues say things like, "I want to understand your problem." "Can you explain that another way?"

The other thing I have noticed over my career is that most people do not take criticism well, and it's getting worse. Also, too many people take criticism personally, such as when I criticize a product and not a person, they still take it personally, and it's getting worse. When someone at work finds a problem in my code, writing, etc., I thank them, "Good catch. Thanks." I never see that in forums such as this.

Back in the 80s, when I started my career, people were far more resilient (tough). We would have a serious discussion, and after, go for a beer and laugh at ourselves. These days, there are too many snowflakes who cannot solve serious problems because they cannot have serious discussions.

I see the value in Gradle, but I also notice it is still an immature product with many rough edges. People only want to talk about how wonderful Gradle is, and they get offended when someone suggests Gradle could be improved. I would like to see Gradle improve, and I have many insights into how it could be improved.

<@U03AFQVC16K>, thanks for the references. Currently, I am taking <https://learn.tomgregory.com> as I really enjoy his style of teaching. Also, he is very open and honest that "Gradle can be hard at first," something I too rarely hear. I have also realized that no one else on my team has the incentive to become a Gradle expert, so I have begun that journey because we need to do Gradle much better than we have.

<https://www.youtube.com/watch?v=gH4yVGVOwh0|Jonathan Haidt on Resilience &amp; Mental Toughness>

Actually, I would welcome if you would improve your communication skills as well.
For example you say that I'm often confusing, but that is just your personal (and for sure others) opinion.
I help many people for example here and in the Gradle forums, and most people are fine with my communication and get what I say without a problem.
That you feel different is sad.
But you should also admit that there are always at least two parties in a conversation and you cannot just blame one side for communication problems.

Also I do not see the main problem in me taking constructive criticism personally.
I just don't feel the need to bend to make you happy in my sparse spare time that I could also spent in other ways.
I have no problem with people complaining about my code or similar in a constructive way but also are happy about being told where I did bad and can improve.
You did not offer me to improve my communication, you became personal when all I tried to do was to help you.

I don't think I "act immature" in offering to let other people help you that you can understand better.
Especially as you for example said that Eric clarified the conversation while from what I see and understand he just said exactly the same as I did.
If what he said is really so much different from what I said, I *have* to blame it on my English skills even if Tony of course again tries to bash me as usual, but I just don't see it.
So my offer to let other people help you was just a try to be constructive and not raise your frustration about Gradle by being helped by a person you don't understand.

Also implying that I have self-esteem problems because I say that something is working here is an impertinent infamy by you again, which adds to me just not wanting to help you any more.
I'm not even just saying "it works here", but "it works here, what is the different situation at yours that makes it not work, so I can help", to show that the particular functionality we are talking about
is generally working fine and that I need more information for being able to help you, not to glorify Gradle as flawless or whatever.

&gt; When someone at work finds a problem in my code, writing, etc., I thank them, "Good catch. Thanks." I never see that in forums such as this.
Well, I see it regularly and also say it regularly.
That you don't see it does not mean it is not there.

&gt; I see the value in Gradle, but I also notice it is still an immature product with many rough edges. People only want to talk about how wonderful Gradle is, and they get offended when someone suggests Gradle could be improved. I would like to see Gradle improve, and I have many insights into how it could be improved.
I never said anything different.
Of course Gradle has still problems - like any software does.
I'm also the author of many Gradle issues and Gradle PRs, so I obviously know very well that Gradle has much room and need for improvement still.
If someone is offended by the suggestion that Gradle could be improved, that's just ridiculous.
That doesn't change that in my opinion Gradle is the best build tool available even in its current state.
But that does by no means mean that it cannot or does not have to improve.

<@U045HSQL5CH> I told myself not to react a few days ago. But now I feel that I have to.
I found it very rude that you are keep trying to discredit Vampire. It makes no good and it just harms the community. There is no need to repeat it over and over again.
People are different, we all are different and that is the beauty of us - we do not walk in straight lines. The world around us is trying to draw new lines and punish everybody who is not willing to follow them. In communities like this one we try to put the differences between us aside and focus on core issues themselves. It is not fair to expect that everybody here will please you in every way.

Well, both <@URQ797WRW> and <@U02L3RD6ESY>, as well as others have indeed demonstrated what Jonathan Haidt talks about in <https://www.youtube.com/watch?v=gH4yVGVOwh0|Resilience &amp; Mental Toughness>.

just edited the message, unintentionally hit `enter`  :sweat_smile:

Your suspicion seems pretty correct, yes.

Add a redirect from stdout to stdin using `2&gt;&amp;1` like `./gradlew assembleDebug 2&gt;&amp;1 | tee assemble.log | sed -n '/FAILURE/,/BUILD FAILED/p'`

Afair, the aggregated reports are always for one specific test suite type. But if you want it over multiple types, you can probably just do the same the plugin is doing, just with multiple types.

And / or a candidate for a feature request I'd say if there is none yet

I'm guessing i need to do something here? <https://github.com/gradle/gradle/blob/a45bfed1cd64efe32d8ca4f4414250247d5b3738/subprojects/jacoco/src/main/java/org/gradle/testing/jacoco/plugins/JacocoReportAggregationPlugin.java#L111|https://github.com/gradle/gradle/blob/a45bfed1cd64efe32d8ca4f4414250247d5b3738/sub[…]radle/testing/jacoco/plugins/JacocoReportAggregationPlugin.java>

Yeah, you probably need to use multiple artifact views

ok i'll see what i can do over the weekend, thanks! if you think it's worthy of a feature request and i get it working i'll create a PR

I personally do. No idea whether the Gradle guys will like / accept it or not.

Not really a Gradle question, more for the Android Gradle Plugin probably I guess.
If you run with `--stacktrace` you should get a full stack trace, maybe that helps already.

Or maybe <#CJYS1DAP5|> has people familiar with the problem

My question is about the gradle version because it said Gradle 7.0 but the gradle that I have in my project is 6.2. I don't understand where is that 7.0 from

Besides that you should not use `-all`, but `-bin`, that is just a warning telling you that you use deprecated things that will make your build incompatible when you try to upgrade to Gradle 7.
That has nothing to do with the failing task.

whyd does it takes 7.0? My project has the 6.2

It does not, it used 6.2.
Again, it tells you that you used things that are deprecated in 6.2 and that will be removed in 7.0 and thus makes your build incompatible to just upgrade to 7.0.

&gt; ```[stderr] &gt; Compilation error. See log for more details```
Have you checked what the compilation errors are?

How can I do it from expo build? (using eas)

no idea, not familiar with that.  The errors are printed to stderr, should be somewhere on the screen output earlier.

I think that the under what went wrong is the error:
``` * What went wrong:
1758
[stderr] Execution failed for task ':expo-barcode-scanner:compileReleaseKotlin'.
1759
[stderr] &gt;
1760
[stderr] A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction```


no, it says the same thing, “see the log for the compilation errors.”

Do you know where I can find support for this? It’s driving me crazy

Not really a support issue.  Standard compilation errors.  Scroll back and look for them and action from there.

Hello! I have read a few mentions lately about goals of learning Gradle in the next year. We have recently published a learning journey on <http://gradle.org|gradle.org>. The highlighted courses are running and we are developing the other courses now. We do not have the dates up for the training next year yet but keep in mind that these new trainings are all free, you are also welcome to encourage your whole team to sign up for the same one. No seat limits :slightly_smiling_face: Or if there is a course that you think your team needs let us know and we might be able to do special session. Let me know if you have any questions!

Can you specify how to see the problem?
When I clone your project and run `./gradlew build` it complains that it uses an invalid target version.
When I try again with Java 17, I get compile errors from `:micronaut-form-login:compileJava`

intellij gives you warnings in the build tab and then does not show the tasks in the gradle tab. this is still useful feedback that i guess it is basically not visible at all if not looking

Ah, I see, thanks.
You have plugin `io.micronaut.application` applied on `:gallery-sharer` and on `:micronaut-form-login-text` sibling projects individually.
This way they end up in different class loaders and so class `GraalVMReachabilityMetadataService` is present twice, once on each class loader and incompatible as they are different class instances if they come from different class loaders.
So if classes from the one want to communicate with classes from the other, you get a problem.

If you make sure both projects get the classes from the same class loader by adding the classes to a common parent class loader it works.
So if you for example add a `build.gradle` for the root project and put in it
```plugins {
    id 'io.micronaut.application' version '3.6.6' apply false
    id 'io.micronaut.library' version '3.6.6' apply false
    id 'com.github.johnrengelman.shadow' version '7.1.2' apply false
}```
and also change the `io.micronaut.application` version in `:gallery-sharer` to be the same 3.6.6 version (or you can also leave out the version then), it works properly.

works like a charm, how did you know that they would be the same class loader if loaded up from a parent build.gradle?


(anything to read up on? going to try to apply this pattern elsewhere - seems like the way i was doing it will stop working when eventually other plugins also add build services.)

I just know the class loader hierarchy in Gradle roughly. :slightly_smiling_face:

I think there once also was a blog post about it

But you can also simply use a debugger to see where various classes come from

And the class loaders have pretty meaningful names to see the hierarchy

ill keep an eye out for those i guess <https://www.google.com/search?q=site%3Ablog.gradle.org+classloader>

Maybe this one, maybe a different, I don't remember: <https://dev.to/autonomousapps/abusing-gradle-s-class-loader-hierarchy-for-fun-and-profit-oca>

"Above that is buildSrc itself, which is the historical source of primordial evil in Gradleland." :rolling_on_the_floor_laughing:

I managed to solve this by making the dependency `compileOnly` and then creating a task that copies the class files from the lib build directory to the app build directory. I then add
```    build {
        finalizedBy(copyLib)
    }```

so now when I run `gradle build -t` it will always copy all the compiled classes across which the ktor server then picks up

Be aware that this is quite problematic.
I don't know what the better solution is, as I don't use ktor.
But tasks should not share outputs / write files into output directories of other tasks.
Otherwise you disturb some Gradle features like up-to-date checks, task output caches, and so on.

yeah it’s fine because it’s just a development server and is not packaged up or used anywhere, but thanks for saying. I haven’t found another way though?

What kind of loop? Does the finalizer task change something of the original tasks’ output?

Kind of, see his thread right above this one.
He now has a task that copies project dependency compile output to the dependee compile output directory and makes `build` finalized by that task. :confused:
The question is, what is the proper way to get ktor hot-reload working properly.

Is it possible to have a different location where both compile outputs can be copied to and ktor picks up those changes?

Given the work-around in the issue <@U02FGCZ29EH> linked to the place where ktor looks at seems to be configurable.

I could not see any way to configure the root location that ktor picks up though, their docs only say you can advise what locations inside the `build` directory, not where this `build` directory is

I imagine it’s possible but I couldn’t find any guidance <@URQ797WRW>

I just assumed the `ktor.deployment.watch = [ /build/classes/ ]` in `application.conf` in the work-around in the issue you mentioned would do that.
But as I said, I'm not using ktor, so I don't know

the thing is that it wants
```ktor.deployment.watch = [ classes ]```
i.e. not the `/build/` part

so if I want to put these files somewhere else, I suppose I could copy them into `/build/dev` or something

Did you try?
Maybe it works because of the `/` in the beginning.
As I said, I'm just guessing here from what I see in that issue work-around.
But yeah, if it has to be something in `build`, that's not too bad either, as I wouldn't put build output anywhere else anyway. :slightly_smiling_face:

ok, I had a try and it seems that either it doesn’t like and ignores entries like `../../../mymodule/build/libs` or doesn’t reload jar files (since the module is packaged up into a jar file)

I just checked and the jar file does get updated correctly but I guess ktor doesn’t reload jars

I'd guess you then need something like `../../../mymodule/build/classes/` or similar

I tried that but I think the issue is that it still doesn’t reload the jar, so I think there might be no escape from doing something like what I’ve done and manually provide the class files etc instead of the jar. If I put these files somewhere other than the build directory then I guess I can just add it to the classpath in the JavaExec job?

so I added the following to my ktor config
```val watchPaths = listOf("classes", "resources", "$workingDirectory/output")```

and in gradle I changed my copy task to copy the files to an “output” directory which is not in the build directory

added it to the classpath in the JavaExec task and voila!

thanks for your help and encouragement <@URQ797WRW> and <@UA8P8BBEG>

Tooling API should expose what you need.  That is what IDEs, for example, use to gather dependency information.

Could you direct me to the exact place to see repositories, for instance?
I've studied the objects below, but found no information on repos or deps. Well, there was a list of classpath dependencies in Eclipse model (found that on SO), but I need tree, not flat list.

Well, since Gradle files are valid Groovy files, looks like I need to parse Groovy AST and extract necessary data. I see no easier way to do so.

use the Tooling API (you’ll need to track down examples).  The source files (which may be Groovy or Kotlin) don’t reflect the processing to generate the dependency model, including conflict resolution, constraints, etc.

You could look into JetBrains IDEA code to look how they analyze Gradle build though it could be quite convoluted. <https://github.com/JetBrains/intellij-community/tree/master/plugins/gradle|https://github.com/JetBrains/intellij-community/tree/master/plugins/gradle>

Another way is to inject your own gradle scripts via init script to analyse for example repos using just a standard gradle APIs. I used such approach in functional tests for settings plugin: <https://github.com/grossws/private-repo/blob/main/src/functionalTest/kotlin/ws/gross/gradle/PrivateRepoPluginFunctionalTest.kt#L288-L301|https://github.com/grossws/private-repo/blob/main/src/functionalTest/kotlin/ws/gross/gradle/PrivateRepoPluginFunctionalTest.kt#L288-L301>

Hello, I am getting this error message and do not know if it is because of fault on my part or my professor has created some kind of error in the Gradescope code. This is my error message for my final and I have no idea how to work around it.

If a java process exits with exit code 137, it usually indicates an out of memory error. In this case I would suggest trying to give the forked test process more memory. Take a look at this documentation for possible configuration options: <https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html>

Does gradle support dependency substitution of included builds in the `buildscript` blocks? Everything works fine in the top level `dependencies` block.

Not really. How long is it pending already?

Then you shouldn't be that impatient, but wait 2-3 days more. Until then it should be done usually.

yeah, even though manual publication happens only for the first version of a plugin (or if the plugin’s GAV changes), it can be slow sometimes… we’re not too resource rich.. on the bright side though we are actively gathering metrics to try to obtain more resources for the team responsible. btw. this particular plugin has been already approved a couple of days ago

This is the corresponding PR: <https://github.com/gradle/gradle/pull/22232>

Maybe you should ask there :slightly_smiling_face:

Or maybe <@U02AA235DGC> can drop a word here

Oh, thank you, I missed that the upgrade guide specifically mentioned the need for plugins to be recompiled.

<https://docs.gradle.org/8.0-milestone-6/userguide/upgrading_version_7.html#report_getoutputlocation_return_type_changed_from_provider_to_property|https://docs.gradle.org/8.0-milestone-6/userguide/upgrading_version_7.html#report_getoutputlocation_return_type_changed_from_provider_to_property>

BTW, if you need to support multiple Gradle versions, this is possible since Gradle 7: <https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html#plugin-with-variants>

Out of curiosity (I'm not related to the development of the aforementioned plugin), and to follow on the idea to provide different variants, how would you approach the need to target versions 7 and 8 in that specific situation, where we have source compatibility (only the return type got changed) ? Any way for compiling against an _arbitrary_ Gradle API, as `gradleApi()` only provides the _current_ API?

There is nothing built-in yet, but the Nokee guys publish those jars

<https://docs.nokee.dev/manual/gradle-plugin-development.html#sec:gradle-dev-redistributed-gradle-api>

Nice to know, thank you :slightly_smiling_face:

Hi <@U029ZH9SZQS>, you are correct this changes a stable API during a major version upgrade.  Thank you, <@URQ797WRW>, for pointing out the note in the upgrade guide.  You will have to recompile plugins that are statically calling this method.

We have a problem with applying the standard lifecycle in the case of wanting to narrow or otherwise change method return types while keeping method names constant.  If we `@Deprecated` the method, then we have to provide a replacement - but it wouldn’t be a _permanent_ replacement, since we want the API to keep the same method name.  If we did this, anyone wanting to keep their builds free of deprecation warnings would have to migrate to the new method.  Then, once we `@Deprecated` _that new method_, they would have to migrate back.  This would stretch out the migration cycle and introduce a lot of churn on both our side and the author’s side.

We have identified many other APIs where similar improvements could be made, for instance `SourceSetOutput`, where `FileCollection` return types really ought to be `ConfigurableFileCollection`s, and are thinking about better ways to ease the pain of transition for plugin authors for 9.0 and later major versions.

We hoped that this particular change would be small enough that it wouldn’t affect most authors, but realized the potential consequences.  We have other potential work in this area of the API that could require it, which is why we went ahead, along with issuing a warning in the upgrade notes.

&gt; Any way for compiling against an arbitrary Gradle API, as gradleApi() only provides the current API?
We are also discussing potential ways to make this easier.

Sorry for the trouble this may cause, but we hope it’s ultimately worth it as we continue to evolve our API to be more consistent and useful.

IIRC the bytecode can contain overloads with same argument list but different return types, you just can't write such a thing in Java; so maybe an annotation on the methods and some post-processing of the compiled bytecode could add back those signatures to keep binary compatibility? (and if the method in bytecode is properly marked as a synthetized method –or whatever the name– then compiling against the new API would "link" to the new method so it's forward-compatible with Gradle 9 or 10 that would remove the bytecode manipulation)

Such a "trick" would be great if possible, simplifying upgrades for users and plugin providers.

This is pretty much exactly what has been suggested and we’re researching if it could work.

if you write in Kotlin, it will compile this just fine
```fun foo(): SomeType

@JvmName("foo")
fun legacyFoo(): SomeOtherType```

<@U02AA235DGC>, would you have any news on the research to implement backward compatibility (is there any GitHub issue we can follow)?
Gradle 8.0-rc-2 still exhibits the same symptom (`NoSuchMethodError` for APIs that were not marked as deprecated/incubating); is there any flag I can enable to turn on an experimental compatibility layer?

Or should we just assume that affected plugins will just break with Gradle 8, until authors release a compatible variant/version? (that would delay adoption of Gradle 8)

Nothing specific to share yet.  This is still very much in the discussion phase.

Hey, <@U048H07PLQ3>! Yes, Build Scan comparison is a feature of Gradle Enterprise only and is not available on <https://scans.gradle.com|scans.gradle.com>.

`.plus(..)` does not work bc it converts the value to an `Iterable`

The idea is similar to the Java Library plugin but the difference is I dont want the base plugin to be brought onto the build class path transitively or applied by my plugin

it's possible and I do this myself. My guess without more information is that you're running into a classpath/class loader issue. How is each plugin added to the build's classpath?

The constraint is the user might have requirements of plugin versions.  If they want to use a newer one of the dependee then I want to do nothing. If they dont want the dependee at all, I dont want to bring it along as a compile time dependency

```plugins { 
id 'dependee' version '1.0'
id 'dependent' version '1.0'
}```

```plugins { 

id 'dependent' version '1.0'
}```


The order of the plugins shouldn't actually matter anyway.
How do you "check for the class"?
Can you show an <https://stackoverflow.com/help/mcve|MCVE> of what you try?

Well if the class I need is not on the runtime build class path then a class not found error is thrown.  There is no MVCE really, thats just the reality.

Plugin A -&gt; KlassA
Plugin B -&gt; KlassB -&gt; PluginA:KlassA

Then

```plugins.hasPlugin(KlassA::class.java)```
fails even when the plugin has been put in the `plugins` block first

I will guard with reflection using `Class.forName` but even my real issue is that `plugins` block doesn't bring the plugin classes onto the path during the `configuration` phase

It should, that's why I asked for an MCVE or reproducer. :slightly_smiling_face:

Btw. if you have a look at the JavaDoc of `plugins` (or rather `getPlugins`), you will learn that you shouldn't use it, but `pluginManager` instead. :slightly_smiling_face:

oh this was written back in gradle 6?  I can try upgrading

Also, you might consider using `pluginManager.withPlugin` to react to the other plugin getting applied even if after your plugin instead of checking with `hasPlugin`

That's longer not to be used than even Gradle 6 iirc

So in my plugins `apply`  method i'll try to use `pluginManager.withPlugin` and see what happens

Looks like a bug. `compileClasspath` should resolve the `api` variant, but `annotationProcessor` should resolve the `runtime` variant. If that's not the case, then it's a bug in Gradle.

Should be the case, yes:
```jvmPluginServices.configureAsRuntimeClasspath(annotationProcessorConfiguration);```
I'd say an <https://stackoverflow.com/help/mcve|MCVE >would be helpful.

Could it failed due to the fact, that `project-a` is defined within _implementation_ configuration in `project-b` even though it should be within _api_ (because of project-a's classes are used with _public_ visibility within project-b)? I know, it's a bug on our side.

A dependency should be in `api` if you use its types in the public API like method parameters, return types, superclasses, ...
If you just use the classes in private methods or method bodies, `implementation` is the right choice.
As `annotationProcessor` should be pulling in the runtime classpath, it should also get the `implementation` dependencies. So if `b` has `implementation` dependency on `a` and you only add `b` to `annotationProcessor` of `c`, then the classes of `a` should automatically be present even without an explicit dependency on `a` from `c`'s `annotationProcessor`.

Yop, I know about the API like methods and how to distinguish api and implementation configurations. I just didn't expect we have a bug there. Which I have just discovered.
So it should work, thanks. Here is the example:
<https://github.com/little-fish/mcve-gradle-annotation-processor>

```14:58:41: Executing 'classes'...

&gt; Task :project-a:compileJava
&gt; Task :project-a:processResources NO-SOURCE
&gt; Task :project-a:classes
&gt; Task :project-a:jar
&gt; Task :project-b:compileJava
&gt; Task :project-c:compileJava
&gt; Task :project-c:processResources NO-SOURCE
&gt; Task :project-c:classes

BUILD SUCCESSFUL in 25s
4 actionable tasks: 4 executed
14:59:12: Execution finished 'classes'.```

Only thing I changed to your commited state is that I replace the bad `-all` by the good `-bin` :slightly_smiling_face:

Wait what? What's wrong with -all? -bin fails on my machine as well. (Btw I am using Java 8)

`-all` is helpful in exactly one situation.
If you use Groovy DSL build scripts and only while editing the build scripts.
In all other cases, it is just a waste of time, bandwidth, and disk space for everyone and everything just executing the build

Hm, interesting, I executed with Java 11 when it worked.
With Java 8 I get the same error.

I thought that its just one time download. In such a case I rather have everything ready for build script editing ,) 

Correct me if I'm wrong but this has nothing to do with `annotationProcessor` then? In the MCVE, `annotationProcessor` only includes `:project-a`, not `:project-b`-that-has-a-dependency-on-`:project-a`. This looks more like something to do with either the `spring-boot-configuration-processor` and/or JDK annotation processing, and would likely work the same with Gradle out of the equation.
```Caused by: java.lang.IllegalStateException: Error processing configuration meta-data on foo.bar.c.Bla
        at org.springframework.boot.configurationprocessor.ConfigurationMetadataAnnotationProcessor.processElement(ConfigurationMetadataAnnotationProcessor.java:218)
        at org.springframework.boot.configurationprocessor.ConfigurationMetadataAnnotationProcessor.process(ConfigurationMetadataAnnotationProcessor.java:172)```


It is a one-time download if it is already there.
If you for example build on an ephemeral build agent or in a docker image, it will always be redownloaded.
And even if it is just downloaded once, it still wastes disk space unnecessarily

Regarding the MCVE, I guess this is a Java compiler bug as it works with Java 11.
But actually you have `A` as annotation processor dependency and `B` as `api` dependency which then misses `A` for compilation.
If you add `A` as compile dependency in `C` where it is missing, it also works with Java 8

<@UDC9Q9RD0> You are correct. I fixed the dependency within the MCVE.
<@URQ797WRW> To be honest, I am lost between `A`, `B` and `C` :slightly_smiling_face: Can you be more specific please?

&gt; You are correct. I fixed the dependency within the MCVE.
Changes nothing to the problem: likely a bug in the JDK and nothing to do with Gradle; in the MCVE I don't even understand why the projects are added to the `annotationProcessor`.

My initial thoughts were based on the fact that if I change `project-b`'s dependency on `project-a` to `api` (instead of `implementation`), it works fine. So I tried to add the dependency directly to the `project-c` 's `annotationProcessor`.

But as I said, it is not missing on the `annotationProcessor` class path, but on the compile class path.
So if you add it to `project-c`'s `api` or `implementation` it works even with Java 8

Oh, I see. Thank you guys for explanations.

GitHash.kt

Source code for this. `providers.gitHashDev(project)` is the function call I’m using to set the `BuildConfig` field for the git hash

Not 100% sure, but I guess the problem is because you are too fine-grained.
I think the parameters of the dev value source are resolved and thus the actual value source is resolved and if it then changes its return value, it invalidates the CC entry.
I think if you do it directly within one value source, the property checking and then calculating the actual hash or the dummy value, it will probably work out better.

The issue is the `.get(..)` being called during the configuration phase, and part of the value source changing!

Untitled.kt

I want to mock `git rev-parse --short HEAD` to return a hardcoded value, instead of the actual value. I need to rely on whatever logic Gradle is internally using around `ExecOperations` for this so I can write a test to see if the config cache is invalidated when this changes

note: this is a test for the problem here: <https://gradle-community.slack.com/archives/CAHSN3LDN/p1671736819660289>

but just make a `:buildSource` folder and include it

The article I read recommends against a `buildSrc` directory, and the GitHub project does not use it either.

The question is, "in light of the two references, do people still recommend `buildSrc` and why?"

It's more of an opinion question than right or wrong question.

I don't think anyone recommends `buildSrc` these days

Thanks, <@UMCNY0BFH>, I am taking Tom Gregory's Gradle course, so it may be a little outdated, or I have just not gotten to the end of the course yet.

I don't know this specific course but yeah things change fast. There are still occurrences in the Gradle doc too

Oh, yea... one of my central problems is how rapidly Gradle evolves and how much out-of-date documentation Google search finds... :face_with_rolling_eyes:

Official doc is good but yea lagging a bit sometimes in terms of best practices

<https://youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE|https://youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE> is my source of truth these days for best practices

I am playing with Gradle 8.0, and trying to learn from that documentation. Already I can see the improvements in that documentation.

<https://docs.gradle.org/current/samples/sample_convention_plugins.html|This doc> is probably the first one people see when googling convention plugins in gradle, and it still uses buildSrc

Yup, that is how I started using `buildSrc` and it's still there in 8.0 documentation...

<@UT8DZBKHV> yea, that's a pain. I wanted to make a PR at some point but I don't think the docs are open source:-(

I am documenting what I am learning in a `GRADLE-CONVENTIONS.md` file in my project.

You can contribute to the docs here. :slightly_smiling_face: <https://github.com/gradle/gradle/tree/master/subprojects/docs>

How is the Gradle knowledge in chatGPT coming along? :wink:

Actually, a lot of chatGPT is out of date too, but not as bad as Google search...

Well I do know it can write some good poems about Gradle. :slightly_smiling_face:

<https://gradle-community.slack.com/archives/CRA9GTYBH/p1669800149275429>

So considering the work done in <https://github.com/gradle/gradle/issues/2531#issuecomment-1354506556>, what would be the status of recommending includeBuild over buildSrc? Or would this not change the recommendation.

Okay, I am trying to follow
```<https://github.com/jjohannes/idiomatic-gradle>```
There is a lot of setup involved... a lot of complexity going on

Set up convention plugins, that's the key thing

Yep... going slow as I am apt to make typos...

I see similarities in using `buildSrc` but way more intense...

Extreme 'separation of concerns' -- not that that's a bad thing...