5 ms·

> Do I have to spin up a whole session of the IDE just to run my test suite? In the java ecosystem at least, the answer is no. But in highly CI-based situation

> Do I have to spin up a whole session of the IDE just to run my test suite? 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.

szatkus 5y ago
In my current organization I saw a project, where there is no Maven. The build system is a couple of configuration files for Eclipse IDE and that's the only way to run it. I'm glad I didn't have to do anything around that.
- AmpsterMan 5y ago
  My team used to have stuff off that nature after we inherited the code base. Acquisition and movement of HQ meant a brand new team on a 15 year old B2B SaaS. Trying to move away from the combination of shell scripts, perl scripts, eclipse config, etc. Over to Gradle has been painful, but with it for onboarding new devs.
- eropple 5y ago
  That definitely does happen with really poorly considered starting points, but in my experience it's also maybe a day's work to pull that apart and put it into Maven/Gradle (unless you've also got, like, some really terrifying ant stuff to go with it, and even then you can sometimes ask "is this even necessary?" and get with the chopping down). IntelliJ even has tooling to get you started: https://www.jetbrains.com/help/idea/convert-a-regular-project-into-a-maven-project.html https://www.jetbrains.com/help/idea/convert-a-regular-projec...
- touisteur 5y ago
  The ant eclipse plugin does some lifting for you. Sometimes, it can be better this way than having 2 buildthings not in sync... But yeah ant all the way if everyone's happy with it...
- eitland 5y ago
  I had to fix one such case 6 years ago where the build procedure was to build in IntelliJ. 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.
wheybags 5y ago
If you're not familiar with them, have a look at visual studio SLN files. They are exactly what was described. There is more and more being pushed into the msbuild files instead (a separate format, that is at least theoretically separate from visual studio) but the weird and underdocumented sln file still exists. And msbuild files are absolutely unreadable XML crap anyway, good luck writing one by hand.
- bccdee 5y ago
  > have a look at visual studio SLN files. They are exactly what was described. You nailed it in one — visual studio is exactly what I was complaining about.
bccdee 5y ago
>> Do I have to spin up a whole session of the IDE just to run my test suite? > 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.
- jeffterns8 5y ago
  Poor project management != fault of IDE, it's the one responsible for choosing to configure the project in said way. That's not dismissing the fact that VS and other IDEs allow, and even recommend, nasty setups but, unless they force them, I don't see blaming optional features or poor usage of a tool as a rational reason to write off an entire toolset that can be powerful and productive.
  - bccdee 5y ago
    It was an older project — from what I've heard, better VS project structuring has only been possible in newer VS editions.
    - jeffterns8 5y ago
      How old are we talking? I've worked with versions of VS since VS 2005 and don't recall ever having issues with project structuring.

szatkus 5y ago

In my current organization I saw a project, where there is no Maven. The build system is a couple of configuration files for Eclipse IDE and that's the only way to run it. I'm glad I didn't have to do anything around that.

AmpsterMan 5y ago
My team used to have stuff off that nature after we inherited the code base. Acquisition and movement of HQ meant a brand new team on a 15 year old B2B SaaS. Trying to move away from the combination of shell scripts, perl scripts, eclipse config, etc. Over to Gradle has been painful, but with it for onboarding new devs.
eropple 5y ago
That definitely does happen with really poorly considered starting points, but in my experience it's also maybe a day's work to pull that apart and put it into Maven/Gradle (unless you've also got, like, some really terrifying ant stuff to go with it, and even then you can sometimes ask "is this even necessary?" and get with the chopping down). IntelliJ even has tooling to get you started: https://www.jetbrains.com/help/idea/convert-a-regular-project-into-a-maven-project.html https://www.jetbrains.com/help/idea/convert-a-regular-projec...
touisteur 5y ago
The ant eclipse plugin does some lifting for you. Sometimes, it can be better this way than having 2 buildthings not in sync... But yeah ant all the way if everyone's happy with it...
eitland 5y ago
I had to fix one such case 6 years ago where the build procedure was to build in IntelliJ. 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.

wheybags 5y ago

If you're not familiar with them, have a look at visual studio SLN files. They are exactly what was described. There is more and more being pushed into the msbuild files instead (a separate format, that is at least theoretically separate from visual studio) but the weird and underdocumented sln file still exists. And msbuild files are absolutely unreadable XML crap anyway, good luck writing one by hand.

bccdee 5y ago
> have a look at visual studio SLN files. They are exactly what was described. You nailed it in one — visual studio is exactly what I was complaining about.

bccdee 5y ago

>> Do I have to spin up a whole session of the IDE just to run my test suite? > 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.

jeffterns8 5y ago
Poor project management != fault of IDE, it's the one responsible for choosing to configure the project in said way. That's not dismissing the fact that VS and other IDEs allow, and even recommend, nasty setups but, unless they force them, I don't see blaming optional features or poor usage of a tool as a rational reason to write off an entire toolset that can be powerful and productive.
- bccdee 5y ago
  It was an older project — from what I've heard, better VS project structuring has only been possible in newer VS editions.
  - jeffterns8 5y ago
    How old are we talking? I've worked with versions of VS since VS 2005 and don't recall ever having issues with project structuring.