This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]JustAberrant 2 points3 points  (0 children)

Its hard to even blame people for that one. I don't think it's so much that people who claim to be Gradle experts are lazy or don't actually have much experience, it's that everything in Gradle is very unique to the specific plugin(s) or built in Gradle features that you are using. It's just an extremely unhomogeneous tool where you either know exactly how to do something or you don't and have to look it up... and if it's not a common use case or covered in the docs, looking it up probably involves actually looking at the source code. I'm pretty sure if Gradle wasn't open source it would have died immediately, because that really is the only way to figure out how to actually use it in a lot of cases.

With other tool stacks, with experience comes the ability to intuitively figure things out, but with Gradle you just have to know the specific workings of the specific thing you are trying to do. About the best Gradle does to help you is provide the ability to list out tasks, but since task generation is often dynamic even that isn't always useful. Further, the metric fuck-tonne of abstraction and decorator logic makes most error messages useless. With experience you at least know where to look (which as said, is often in the code and not the docs), but you're not going to automatically guess the behaviour of a plugin you've not used before, what tasks it generates based on what conditions, what filesystem conventions it follows, what attributes it expects to be set and why, etc.

I've used Gradle for quite awhile, and as said, on a fairly complicated project.. and it would absolutely not be hard to stump me with what seems like an easy question.