This message was deleted.

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 @Vampire 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

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. 🙂

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 <task>

and

./gradlew :<task>

.

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 @tony on this, but still the behavior is unexpected and problematic.

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. 🙂

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?

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. 😕

The second problem with Gradle is people telling me

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.

The second problem with Gradle is people telling me

> 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. 😉

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.

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

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. @Vampire 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

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.

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 @Vampire, 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.

@Eric Kolotyluk assuming you're new here and you don't know that @Vampire 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 @Vampire) who would likely still go out of their way to help you.

@Eric Kolotyluk 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 @Vampire 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 @Vampire 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.

@Eric Kolotyluk I am really glad you are learning Gradle! Some resources I recommend • our in house training here or linked here • Video series by Gradle Fellow Jendrik • Blog posts by Gradle Fellow Tony

@Eli Graber, 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, @Eric Haag clarified the conversation more directly. @tony is consistently clearer in his communications, so I value them much more highly. @Eric Haag 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. @Amanda, 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.

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.

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.

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.

@Eric Kolotyluk 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 @Vampire and @tomas-mrkvicka, as well as others have indeed demonstrated what Jonathan Haidt talks about in .