Ranter
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
Comments
-
Usually the DI bootstrapping and --stack-trace or debug will spit out the offending reference. It is very obtuse though, I agree.
Still better than maven and ant. -
@SortOfTested
I think the issue is the ancient heritage, and resulting feature & tooling bloat. Powerful, but bloaty.
Just trying to grasp the process of "get library and make it available to my code" -- You'll encounter terminology like Gradle, Plugins, Tasks, Maven, Ant, POM, JAR, Ivy, Groovy, Kotlin DSL, Grape, Artifacts, Modules, Projects, runtime vs compile vs implement vs api dependencies, configurations, Transitives, resolving vs consuming, Multiproject building, etc
There are of course parallels to other packaging tools, so some concepts click in place pretty fast, but it does remind me of the persistent tooling rash which is common when exposed to that STD called Javascript. -
@SortOfTested I was going to argue with you, that Maven isn't so bad. But then I remember the pain that is multi module projects with inheritance. Also pom imports.
I really like Kotlin as a language, but Gradle makes me feel nauseated.
Pulling in deps without getting errors, then the library won't resolve because of some version mismatch (still, no error or warning on build, until I try to import the dependency in the code, and then just "unable to resolve <library>" without details). All of the documentation on the internet is either super specific for Android projects, or for an ancient Gradle version. Feels like I'm back in Haskell's "Cabal Hell".
*runs back into the loving embrace of Cargo*.
What was I thinking, trying to write an application in something that's not Rust.
rant