There are those moments you wish you could just start up a real database or system for your (integration) test. In many tests I’ve written I used H2 or HSQLDB to have a data storage for my tests. It starts up quickly and almost supports everything you need to do your repository test or any other test needing data storage. But when your project progresses you start using other ways to store your data other than standard SQL or you use dialect specifics to create your database. This is the moment you discover H2 or HSQLDB is not supporting your database vendor specific features and you can’t get your test running. For example the support for PostgreSQL in H2 or HSQLDB isn’t great, using TIMESTAMP in a SQL script already makes H2 or HSQLDB break. Yes, there are workarounds, but you rather not apply them to keep your code clean and simple. This is the moment you wish it is cheap to start up a real database instance you can test against, so you’re sure your code works in your production environment. You could install the database software locally, make some scripts to initialise the database and clean up afterwards. Or you can make scripts to do this in a Docker container. But what if there’s something which makes this even cheaper to setup?
Posts by Tom de Vroomen
Making IntelliJ understand your QueryDSL generated classes needs some work. QueryDSL has an annotation processor to generate Q-classes from your entities. Just running the annotation processor doesn’t mean your IDE will understand where to find the generated classes. I was struggling to get IntelliJ IDEA picking up the generated classes. Probably there are more ways to get this done in Gradle, but I found out one that’s pretty easy to configure, without any adjustments to you IntelliJ settings. Because you could configure the annotation processor via the IntelliJ settings in the Annotation Processor screen (Build, Execution, Deployment → Compiler → Annotation Processors). It would be easier if you can achieve the same just using Gradle. With the following in your Gradle build file, it generates the classes and instructs IntelliJ where to find the classes:
Maven can be set up to use a private repository, i.e. Nexus. Usually the repository runs on http and there isn’t any problem to connect to the repository, but when the repository runs on https maven isn’t able to connect to it automatically. The solution to this is to add the server’s certificate to the default Java keystore. When connecting to your https-repository fails, Maven will show you an exception like