Really? You dismiss my clearly-not-ignorant comments by belittling me? OK. I should have known.
Part of the frustration here is this: given a clean sheet of paper, and a desire to write a Java-based web application, where do I start? What files do I download? I don't know! How do I start developing with Spring? The site says "add this line to your build file." WTF does that even mean, to a Java noob? What's the file I'm supposed to be putting that configuration into? Unless you have a file structure bootstrapped, and know that they're talking about pom.xml, in the case of Maven, or build.gradle, in the case of Gradle, it doesn't mean anything!
How did I figure that out? By using an IDE and generating example file structures for a "web application" based on those 2 options in the stack. So getting started with Spring requires an existing bootstrapped structure that I STILL don't know how to generate by hand. (Feel free to enlighten me. How do YOU start a new Spring project?) Hence, my frustration with the various IDE's, and their multiple ways of generating what should be a pretty standard stack of files to get started.
As I tried to indicate, I "get it" that I have a lot of this stuff internalized with respect to Rails, and that's what I'm trying to get across. I don't think that the Spring folks understand what they need to do to "onboard" someone to their system. At least Grails seems to do a better job with this.
When Spring started, there was already a myriad ways of doing stuff, and multiple IDEs, and multiple use cases for Java itself, and Spring was trying to answer a lot more up front.
If you're doing 'web' in Java (something I still think much of the java world still doesn't really 'get'), there are dozens of choices/options/etc. If, in 2006, you were planning to do 'web' and wanted to use Ruby... the primary choice was Rails. If you were doing 'web' and wanted to use Python... you similarly have often only had one or two major choices (I'd argue 'Zope' early on, then Django as a default go-to for the last 10 years or so). In the Java world... way too many choices up front, all answering similar problems, but slightly differently.
While Ruby was out before Rails, their popularity generally rose in tandem, and much of the tooling for the ecosystem seemed to develop in tandem during the progression of Rails itself.
Had Spring started in 1997, we might have seen a somewhat different trajectory re: choice/tooling/community/etc.
I'd suggest not to search for various "stacks". They might be written poorly and incomplete. Learn each part and learn how to combine them.
I guess Rails is a complete solution, with Java there are many libraries which you should choose and glue together. Every non-trivial application probably will use somewhat unique combination of libraries.
The GP seemed to be indicating they were trying to put together a standard set of tools for others in their company to use. Having one official 'blessed' IDE and a 'standard' way to do things - even as a demonstration process - isn't out of the ordinary. And... given how much any complex Java program relies on the author having an IDE handle things for them (the assumption is that an IDE will help find the correct imports when developing, for example), it's pretty common for people to assume you're using one of the few common ones out there. I guess the author was looking for 'free' up front, but I'm curious why they didn't mention IntelliJ - it's the only thing I'd bother with for 'real' Java development in 2018 (although I'm keeping an eye on the vscode landscape).
> should read up on the documentation of the basics of java, gradle and spring first
There's no 'basics' to those - they are sprawling ecosystems, and any non-trivial task requires a pretty deep understanding of how those pieces fit together.
> maybe rails developers expect everything to be spoon fed to them in pieces of 5 minute screencasts or something?
Perhaps other tech stacks are able to deliver useful/functioning tutorials of information in 5 minute screencasts, without requiring someone to be an expert or have years of the 'tribal knowledge' the GP spoke of in another post?
Yup. This is forging a new trail at the company, which is, itself, a painful process.
I was a grails advocate for a long time. I put up with some of the initial pain (from 0.6 days) because it provided more benefit than not. And, had I not picked up intellij, I may have left the fold a long time ago. :)
As time has gone on, the coupling with Spring has become more obvious - I may have just been blissfully unaware earlier on. The migration to a 'spring boot' based approach has sort of soured me more than I expected. If I wanted to use Spring boot, I'd use it. I preferred some of the Grails conventions, but many have been thrown out or reduced to accommodate the Boot way. Some of the stuff I'd hoped to have to dig in to (and, in some cases, had not needed to be an expert in) have now become requirements to dig in to, and I spend more time configuring and digging through framework problems than the actual application.
No doubt much of this is me, but I'd hoped Grails would improve, but for me, it's just changed. My work with Java/Spring/etc definitely has helped me think about problems differently, and improved my thinking and coding overall, but much of what I was looking for has improved in other ecosystems over the last several years to make continuing in the Java world a harder decision. (context: I'm primarily a solo developer, not working with large teams or large budgets). One minor example: being able to make a code change in a test, run that one test, make another change, and rerun the test, all in a few seconds doesn't seem to be something that's possible in the Spring world, and perhaps not in the Java world in general (no doubt there will be people who tell me "you're doing it wrong" and "we run 4000 spring tests every 7 seconds with 0% CPU!" but it's not been my experience).
This was my experience when I began.
What I learned was: unit tests don't need Spring. It seems silly in retrospect, but that's the basic rule. If you need Spring in your unit tests, you probably made a mistake somewhere.
Having worked in a few languages and frameworks, having seen codebases at various levels of maturity and whatnot, I quite like Spring Boot & co. Especially when Kotlin is in the picture.