Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "jacoco"
-
gradle is infuriating.
firstly there are so limited resources to understand how it's building a java/android code. everything happens by magic and hit+trial
secondly the plugins and the tasks works in mysterious ways. sometime they work when applied in the project root's gradle file, other times they work when applied in module's gradle file, nd other times they need configuration at both levels.
then there are gradle tasks like build ,test, assemble , clean etc. these are less of an action and more of an alias to run a bundle of actions.
then we have 3rd party plugins which attach themselves to these "fat-actions" and run before/after them
and finally we have the fuckup from the java world where the only available code coverage plugin is jacoco and IT FUCKING SUCKS!!! it is a test environment plugin, it should impact test tasks , but somehow it's fucking with the assemble taskin such a manner, that the jars ans aar files generated via plugin are giving runtime errrors. yes , runtime! as if we are back in the messed up js world of "everything is good unless running live"
even if it was a compile time eeror, i would have considered. but runtime?!! fucking runtime error?! i barely understand this shit, there is absolutely no info available as to which classes are being used to create a build and how, and i am supposed to fix this? wtf?!4 -
In my Java project, I added a wiremock rule to a few tests. Now my Jacoco code coverage in sonar dropped to 0%. 😩 Maven is running the goals, bit not creating the jacoco.exec file.
That's one of the worst things in Java. Once you understood the concept of immutables, the build tools start to annoy you.2