71–80 of 172 posts
We have Maven builds that can take an hour and Gradle drops that down to minutes (or less than a minute).
Earlier quoted context omitted.
Fix the documentation! Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so. You need to create a LOT of Android Studio sample projects, and they need to be kept up to date for the various versions of Android Studio. If you did nothing but create "Hello World" in a zillion various flavors (Java, Kotlin, Scala, NDK, NDK with static library on different archite…
Thanks for the feedback. Docs/samples oriented around Android could use some love for sure. I think one thing we need to figure out is how Google and Gradle can accomplish these things together.
We refer to that in the corporate world as "death by committee".
You can solve the problem with a GitHub repository and an intern trawling StackOverflow and IRC logs. Choosing not do that sends a signal.
Waiting for Google to "accomplish it together" (aka sometime before the heat death of the universe) is a good way to get replaced.
Xcode/iOS: we published CocoaPods. It was pain to get to work reliably on laptops/Jenkins b/c of upgrades to Ruby, but if you lock yourself to one Ruby version, and lock the Gemfile, it's mostly OK. At least it's pretty obvious when/why it doesn't work.
Gradle: it's such a mess. I don't even know where to start. I don't know Maven, but Gradle error warnings are the worst. 4 lines, tells you nothing, with turned on debugging the output tells you nothing, while e.g.: in reality you don't have the child-repo checked out because you forgot to `git submodule update --init`.
Getting Gradle to work on a laptops across the team of 4 was a pain. We had cases where two people with the same AS version and the same gradle version couldn't import the project into AS. Our instructions are - after 'git pull' make sure you do 'git clean -dfx' and re-import the project.
Personally 50% of time when I start Android Studio I have some critical exception of some sort, each time from Gradle window. There's this, plus gradle wrapper. I pretty much never worked for me. This is meant to solve problems with always getting you the right Gradle version, but this is sci-fi. I believed it's just me who uses SDKMan to be able to fetch the right gradle which our project depends on, but others around do too. Otherwise it's a pain in the ass -- and `brew` doesn't have the gradle's we need, because they migrated to the very latest one, when in production you'd rather have older version for an extended period of support time.
If you, just like us, have a project which has 3+ years of scar tissue and it has to integrate with javanet, picasso, okhttp, volley etc. and you have several people who fetch and integrate your code in their apps--I feel really, really sorry for you.
DSL is all right, and maybe Groovy has some unique features, but I never discovered them. This is Java language that isn't Java, or some dialect of Java-like language aimed to make Java 3% better, but to be honest I don't hear people writing Groovy for fun and pleasure. So to me it was a cost of learning basic stuff just to be able to automate simple stuff in Android build system (when we run ./jenkins.sh --local, we want our Android functional tests to hit local dev environment). Of course in XCode it works 100% better and took 20% of time to do, since Apple owns XCode and made it look better: go to project settings, drop in the path to post/pre built scripts to customize your flow, and in a language you already know. Google, who subleases Android Studio from JetBrains, had no choice and made Android ecosystem look like a Frankenstein.
Earlier quoted context omitted.
Seems "obscure", but it has a schema.
Just to be clear, I'm not against XML at all. Maven does more but can be a pain to program compared to older systems like ant, which is also XML-based. Configuring plugins to fire at the right point in the build cycle (e.g., package vs. install) comes lightly to mind. It's gotten a lot better because there are many examples now accessible with Google. Overall I'm pretty happy with maven now. It works.
That is the main reason I am sticking with Maven (where practical). Examples, documentation, and answered questions are plentiful.
"Configuring plugins to fire at the right point in the build cycle (e.g., package vs. install) comes lightly to mind."
The official documentation has that covered well: https://maven.apache.org/guides/introduction/introduction-to...
An example they give is:
...
com.mycompany.example
display-maven-plugin
1.0
process-test-resources
time
...
IIUC, there are no fixed phases in Gradle, so this sort of thing is done with task dependencies.
Earlier quoted context omitted.
The key point that Gradle needs to make clearer is to delineate between task creation and task execution and which code is running where. It is very confusing for people to know whether their code is going to execute at gradle file load or at task execution. People get confused that they can't just use the result of one task when setting the opts for another. Edit: Also, I personally do the opposite route wrt the par…
Definitely agree with this. The Gradle lifecycle and the difference between Task Execution and Build Configuration is not intuitive at all. Neither is the fact that when you just stick a `<<` or `doLast()` in there without understanding why, it works with some tasks and not with others (killing << is a step in the right direction but making the build lifecycle more understandable would be hugely helpful).
[1] https://stackoverflow.com/questions/11677572/dealing-with-xe...
Probably unrelated, but Java really needs to fix its Classpath Hell issues. On so many sufficiently large Java projects, you end up descending into the inclusion/exclusion madness with your build files because your app is inheriting `log4j` from 50 different libraries. Or the infamous xerces hell[1]. And fixing that in maven is not pretty :(. [1] https://stackoverflow.com/questions/11677572/dealing-with-xe...
I know that this isn't entirely Java's fault, as that second jar shouldn't have been there to begin with, but it's pretty ridiculous that two versions of the same dependency can be loaded and in use at the same time.
I moved from Maven to Gradle about two years ago and I am not going to look back. I understand the arguments made in article and I am the Gradle ninja in my project so I may have subjective view on the whole topic. My points: - Maven requires a lot of boilerplate for everything. Copy-paste. I need to instruct everybody on what to copy, where to paste, and how to edit and what they should not touch under any circumsta…
I moved from Maven to Gradle about two years ago and I am not going to look back. I understand the arguments made in article and I am the Gradle ninja in my project so I may have subjective view on the whole topic. My points: - Maven requires a lot of boilerplate for everything. Copy-paste. I need to instruct everybody on what to copy, where to paste, and how to edit and what they should not touch under any circumsta…
>Maven...you have to write your own plugin. Not nice.
>If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging
You've just explained why I have no interest in Gradle. You're writing one off, undocumented, anonymous plugins, in a weird domain specific language, with debugging tools that aren't very good.
Worse, when the Gradle guru decides to leave the company for greener pastures, everyone else is left with a mess trying to figure out WTH that person was doing in all the build files.