Liquibase with Maven - maven

I want to launch Liquibase for a Java EE - project, so I can make easy DB-Updates at the production server.
I have problems understanding what do i need for the start. I read at many examples that you need to download the liquibase-core, extract it and put the .jar to your PATH. I think that this is not needed for Maven.
To include the dependencies (the core and the liquibase-maven-plugin) at the pom.xml should be enough/ should be the same?
<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>2.0.5</version>
<type>maven-plugin</type>
</dependency>
<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-core</artifactId>
<version>2.0.5</version>
</dependency>
This is probably a silly question, but I have hardly experience with Maven and none with Liquibase.

In my opinion you was a little bit confused with the method to add liquibase to your project. We shouldn't understand liquibase as a simple dependency, it is a maven plugin .
I think that could be clearly if you see some of my config files to understand better what I'm referring to:
pom.xml:
<build>
<sourceDirectory>src</sourceDirectory>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.2</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<excludes>
<exclude>**/test/*</exclude>
<exclude>**/test/me/*</exclude>
</excludes>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<warSourceDirectory>WebContent</warSourceDirectory>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.9.2-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.4.3-01</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>3.5.3</version>
<configuration>
<propertyFile>src/tv/be/persistence/liquibase/code/dsv.properties</propertyFile>
</configuration>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>update</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
dsv.properties:
driver: com.mysql.jdbc.Driver
classpath: [local_path]/mysql-connector-java/5.1.41/mysql-connector-java-5.1.41.jar
url: jdbc:mysql://[db_server_ip]:3306/schema_db
username: user1
password: masterkey
changeLogFile: src/tv/be/persistence/liquibase/code/master.xml
contexts=local
Take attention to dsv.properties file. Each liquibase context needs one proper properties file like that to specify schema and changelog. That provides the ability to work with different environments (dsv,local,test,pro,...) in real time and apply the changes only in the environment/context specified.
Project folder:
That structure is very clean for our team because we have all changelog organized by version and functions, procedures and views separated from root database changes but the greatest thing here is that every change has the issue/task code associated and we can trace everything so easily.
mvn:
To execute liquibase plugin you should execute that mvn command:
mvn liquibase:update
You also can update automatically the database because of liquibase pom's plugin param:
<execution>
<phase>process-resources</phase>
<goals>
<goal>update</goal>
</goals>
</execution>
We use liquibase in several projects and without deeping in the pros of use it, have database version control, history, common logic of diferents projects and maintenance as mandatory for our development team.

Related

How to properly exclude springboot-actuator in pom.xml

Actuator still shows my application health info even after being excluded in the pom.xml
tried following the official doc here
https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/exclude-dependency.html
but still unable to disable it, here is my pom
<build>
<finalName>my-app/finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator
</artifactId>
</exclude>
</excludes>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
i expect my app's health info wont be displayed anymore, but it is still showing when accessed in the browser
Don't use exclusions inside <plugin> declaration, it has nothing with dependencies that get packaged into the resulting artifact
Instead find the <dependencies> section; spring actuator should appear there.
Just remove the dependency on the actuator.
The best way to check that maven didn't include the jar is to check the content of BOOT-INF/lib of the compiled spring boot application
If the build process is complicated and you don't know exactly where does the actuator come from, try to use mvn dependency:tree on your pom, it will should the path to the actuator
Once you figure out that spring boot actuator comes from groupId=X and artifactId=Y, you should exclude it in your pom.xml:
<dependencies>
<dependency>
<groupId>X</groupId>
<artifactId>Y</artifactId>
<version>...</version>
<exclusions>
<exclusion>__here__comes__
actuator_groupId_and_artifact_id__
</exclusion>
</exclusions>
</dependency>
...
</dependencies>

Integration testing Maven jar in a Jetty container

I have a Maven project which produces a jar file that is meant to be used in a web service. It has integration tests which use the jetty-maven-plugin to run.
In order to run the integration tests on the compiled jar file, I've had to create a dependency with <systemPath>${project.build.directory}/${project.build.finalName}.${project.packaging}</systemPath>. The integration tests run as I had hoped, using the compiled jar file and correctly creating the web-app out of the src/test directory.
So in terms of this projects build, this setup works very well.
The problem is that the POM file, which is deployed during the release process, still has the systemPath dependency. This means that projects which use the jar are reporting an error during the build. The error says that the jar file "must specify an absolute path". These builds don't fail, but the logs are cluttered and misleading.
I'm looking to remove this systemPath from the POM which is deployed to our Maven repository. How can we do this?
For reference, here is the relevant portion of the project's POM.
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.0.7.v20131107</version>
<configuration>
<webAppSourceDirectory>${project.basedir}/src/test/webapp</webAppSourceDirectory>
<classesDirectory>${project.build.testSourceDirectory}</classesDirectory>
<useTestClasspath>true</useTestClasspath>
</configuration>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<scope>system</scope>
<systemPath>${project.build.directory}/${project.build.finalName}.${project.packaging}</systemPath>
</dependency>
</dependencies>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<daemon>true</daemon>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Jetty's documentation regarding <classesDirectory> reads:
Location of your compiled classes for the webapp. [...]
So, this should be ${project.build.testOutputDirectory} rather than ${project.build.testSourceDirectory}, shouldn't it?
<useTestClasspath> isn't mentioned in Jetty's doc.
Is it possible to install the dependency and use <scope>provided? Since with that:
[the dependency] is only available on the compilation and test classpath, and is not transitive.
The solution was a slight modification from Gerold Broser's answer.
Here are the relevant sections:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.1.5.v20140505</version>
<configuration>
<webAppSourceDirectory>${project.basedir}/src/test/webapp</webAppSourceDirectory>
<classesDirectory>${project.build.testOutputDirectory}</classesDirectory>
</configuration>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</plugin>

Maven - how to verify that dependencies compiled with specific Java level (1.7 for example)?

For example, Java Maven project have ben compiled with maven-compiler-plugin with target level 1.7 have number of dependencies.
How to verify that those dependencies compiled with some specific Java target level as well (1.7 for example)?
As suggested in the comments, i have used Extra Enforcer Rules as additional dependency to Maven enforcer plugin that provides extra rules, as a solution.
The usage of this functionality described here, and specifically in my code it looks like that:
<properties>
<extra-enforcer-rules>1.0-beta-4</extra-enforcer-rules>
</properties>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>extra-enforcer-rules</artifactId>
<version>${extra-enforcer-rules}</version>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>enforce-bytecode-version</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<enforceBytecodeVersion>
<maxJdkVersion>1.7</maxJdkVersion>
</enforceBytecodeVersion>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>extra-enforcer-rules</artifactId>
<version>${extra-enforcer-rules}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
</build>

how to run maven war dependency using tomcat:run?

I am using maven for my current projects. Now, I have a war dependency:
<dependency>
<groupId>org.dojotoolkit</groupId>
<artifactId>dojo-war</artifactId>
<version>1.8.1</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
I don't have any problem when I built the war artifact. For this, I have added this plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<overlays>
<overlay>
<groupId>org.dojotoolkit</groupId>
<artifactId>dojo-war</artifactId>
<targetPath>js/dojo-1.8.1</targetPath>
<excludes>
<exclude>WEB-INF/**</exclude>
<exclude>META-INF/**</exclude>
</excludes>
</overlay>
</overlays>
</configuration>
</plugin>
But, when I run the following mvn command mvn tomcat7:run I can not see any javascript resource. It looks like war dependency had not been added.
Could someone help me with that?
Thanks in advance.
Welcome to Stack Overflow Emelendez.
You should read this post : http://webtide.intalio.com/2008/07/dojo-toolkit-maven-repository/
Indeed, the dojo-war dependencies allows you to add some files to your sources, but you must specify some extra actions to include it in the final war.
Dependencies, in Maven, can only be in the language you try to compile (well it's not really exact, but this is enough here). If you want to add other resources (files, images, javascript), contained in a zip/war/targz, you must explicitely extract them. This is what is mentionned in the link I provided previously :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack dojo</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.dojotoolkit</groupId>
<artifactId>dojo</artifactId>
<version>${project.version}</version>
<type>zip</type>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/dojo</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
(Be careful, I'm not sure that this configuration is exact, your dependencie seems to be dojo-war according to your pom.xml, and not dojo as per doc said)
This will extract dojo libs into output directory, and then into your war.

How do I execute simple ant call through maven?

My project runs perfectly fine with following commands:
C:\project\<project_name>\ant -lib ant\lib -buildfile applications/<sub-project-path>/ant/build.xml deploy
However, if I wrap this command either in maven-antrun-plugin or exec-maven-plugin in pom, I get all kinds of path issues.
For maven-antrun-plugin, it seems the certain properties can not be loaded due to path issue. In exec-maven-plugin, it seems that ant target never got passed in correctly.
Can someone please advice how I can apply this in a pom file? Much appreciated.
This is my pom for exec:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>ant</executable>
<workingDirectory>${basedir}</workingDirectory>
<arguments>
<argument>'-lib ant/lib'</argument>
<argument>'-buildfile $basedir/<project-path>/build.xml'</argument>
<argument>deploy</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Haven't tried it, but you could do something similar as documented in the maven antrun plugin example.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>ant</id>
<phase>process-resources</phase>
<configuration>
<target>
<ant antfile="${basedir}/<project-path>/build.xml">
<target name="deploy"/>
</ant>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
Not sure what library you want to pass as argument in -lib in your snippet above, but the same can be declared as plugin dependencies.
Do note that this plugin does not care about the existence of an ant installation on your system. It downloads necessary ant libraries.
You should pass needed dependencies directly into antrun plugin declaration, right after <executions> element.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
...
</executions>
<dependencies>
<dependency>
<groupId>ant-contrib</groupId>
<artifactId>ant-contrib</artifactId>
<version>${ant-contrib.version}</version>
<exclusions>
<exclusion>
<groupId>ant</groupId>
<artifactId>ant</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>jasper</artifactId>
<version>${tomcat.compile.version}</version>
</dependency>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>${java.version}.0</version>
<scope>system</scope>
<systemPath>${jdk.home}/tools.jar</systemPath>
</dependency>
</dependencies>
</plugin>
I've included some libraries that I use in our project, so that you have an example. Note, that if your build uses some non-standard ( i.e. something outside java.lang ) Java API classes, you have to pass tools.jar as a dependency.
Also, if you use ant-contrib do not forget to exclude ant as a dependency, because it is dependent on some ancient version of ant and you will get a version collision.
Another annoying thing is that dependency assigned directly to plugin execution are not part of POM's <dependencyManagement>, so you have to spell out precise versions. One workaround is to declare version properties in the same place as your central <dependencyManagement> and use the properties instead of hardcoded versions.

Resources