IntelliJ even has tooling to get you started:
https://www.jetbrains.com/help/idea/convert-a-regular-projec...
It took a day or two to get kt over to Maven: basically create a Maven file, make sure everything were in the correct standard Java layout, then build and unzip the war file and compare it to the unzipped war file from the existing build process repeatedly while getting the last tweaks in place.
You nailed it in one — visual studio is exactly what I was complaining about.
> what are you on about?
This complaint is based on a .NET project I used to work on. I'm sure this isn't universally the case for everything .NET, but I had to work with one instance of visual studio open in the code repository and a second instance of visual studio open in the test repository. Everything we did was configured in and executed through VS. It was pretty nasty.
In the java ecosystem at least, the answer is no. But in highly CI-based situations, the answer is still no, but you DO need the CI system to be up, and the only way to run a test at all is to just commit something and see the CI system run it, e.g. because the tests require a database engine that isn't installed on your development machine.
I'm not saying that's a good idea, just saying that I have seen that in real (as in, for pay and for real eyeballs) dev teams. I've never observed 'I only know how to run my tests inside the IDE'. IDEs (again, this is mostly speaking from the perspective of the java ecosystem) use build tools as project definitions, and those build tests all know how to run the test suite from the command line. `mvn test` is all you need to type.
> Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter?
No, it's `mvn install` or `mvn build` or whatever take on 'build' you are looking for specifically.
If you ditch your IDE, __nothing__ whatsoever would change: Your build is _still_ based on a build tool. (it better be, in the sense that trying to run the build by hand or by patching a bunch of shell scripts together is almost 100% correlated with very low quality dev teams in my experience).
In other words...
what are you on about? IDEs don't abstract such details away to extreme degrees. In fact, insofar that they ever did (generally in GUI builders, which, what with the web and languages like java and Adobe Air and silverlight falling by the wayside in the past few years for front-end dev - are kinda dead), the new takes on such tools all very explicitly keep the whole 'actually this just edits a text file of some sort and this automated click-the-GUI-together tool is bending over backwards to ensure that the underlying file looks as close as possible to what you would write by hand.