Running Liquibase change sets — Part 2: Maven
After a very big pause I’m back with the second part of the Liquibase introduction: how do we run the projects with maven.
In this post I’ll take a look how to get maven to run our Liquibase change sets created in Part 1 of the Liquibase session on a (temporary) H2 database and as a side-effect I’ll show how to get a jar built with the appropriate main class in the MANIFEST.MF file.
The answer is simple: I use Maven since more than three years in my project and I know how it works. I could have taken a look at gradle or other build tools (ant for example) but I stay with Maven. If I have time in the future I’ll get to other tools too — but currently this is no option. If I continue to make long breaks between posts then I’ll never finish the Variations section. So for now we’ll use Maven.
What do ve need? Well, some minor changes in our pom.xml to get the things run. What we need is a build section and a plugin into this tag. That’s it. Take a look at the following code:
<build> <plugins> <plugin> <groupId>org.liquibase</groupId> <artifactId>liquibase-maven-plugin</artifactId> <version>3.1.0</version> <configuration> <changeLogFile>src/main/resources/dbchange/master.xml</changeLogFile> <driver>org.h2.Driver</driver> <url>jdbc:h2:file:./target/db/testdb</url> <username>sa</username> <password></password> </configuration> <dependencies> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>1.3.175</version> </dependency> </dependencies> </plugin> </plugins> </build>
Between the lines 7 and 13 you see the configuration of the change set: change log file, database driver, database location, username and password. As you can see: the database is in the target folder — so with every new maven clean goal our database will be exported to the nirvana and never returns. This is why this is an initial solution with a temporary database. Naturally you can move the H2 data file to any location you like and I’ll do the same in a future step.
How to run?
It is very simple to run this configuration: just open a console, go to the project folder (including the pom.xml) and execute:
After this maven executes the liquibase updates defined in the change-log file — and as a very good side effect you get the local H2 database created too.
Only file based H2?
No. You can use any database you wish: Oracle, MySQL, in-memory H2 or start an H2 server and enter the URL of your running server instead of the file. If you switch to another database provider do not forget to adapt the driver, username and password parameters too.
As always, you can find the code on my GitHub account in the variations repository.
After the long break I decided to get the app running. As you can remember, we created a simple application in the first post of the series and I felt the urge to create a Java Archive (JAR) executable and run the application.
Creating the java application is one out-of-the-box feature from maven. You just have to enter
mvm clean install
and it goes. You’ll get the variations-1.0-SNAPSHOT.jar into your target folder. Very nice to have everything preconfigured.
But if you try to run the application with the command
java -jar target/variations-1.0-SNAPSHOT.jar
you’ll get an exception:
Failed to load Main-Class manifest attribute from<br />target/variations-1.0-SNAPSHOT.jar
OK, so let’s add our main class to the MANIFEST.MF file in the jar — just enter the following code parts into your build-section of the pom.xml and rerun the install of maven.
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <mainClass>biz.hahamo.dev.variations.App</mainClass> </manifest> </archive> </configuration> </plugin>
After this you can run the jar file and get the friendly “Hello World!” message from the default application.
OK, I cannot guarantee that I’ll write the next post within a week or a month. I’ll try to have the next one ready as soon as possible. And what I’ll look at is finally the Java solution of the database versioning with Liquibase: how can you include the changes automatically in your application’s startup process — or add a simple function to trigger the event on demand.
And after that session I’ll skip the intro of Freeway and start some coding to get a running application with our data and database. After this we can change some building blocks of the app (database, change set manager, database layer, IoC container, GUI and so on) and try out how it is on an almost real project.