We Keep Coding

overriding property in maven plugin from command line

This maven command launches an older version (1.3.162) of the H2 database:
mvn -debug com.edugility:h2-maven-plugin:1.0:spawn
As recommended here, I'm trying to override a property of the plugin on the command line....so I can instead use a more recent h2 version:
mvn -debug -Dh2Version=1.4.200 com.edugility:h2-maven-plugin:1.0:spawn
This h2Version property with the older h2 version is defined here on github in the plugin's pom.
Here is the end of the verbose maven output
[DEBUG] Process arguments: [C:\java\jdk-9.0.4\bin\java, -cp, C:\Users\eoste\.m2\repository\com\h2database\h2\1.3.162\h2-1.3.162.jar, org.h2.tools.Server, -tcp, -tcpPassword, h2-maven-plugin, -tcpPort, 9092]
[INFO] H2 server spawned at tcp://localhost:9092
Not only does the old 1.3.162 version launch, but the there is zero mention anywhere of the h2Version property that I placed on the command line.
I tried moving the -Dh2Version parameter to the end of the command line. I also tried deleting the plugin from the local repo, to force a download so maybe the h2Version would then get reevaluated....none of these things worked.
This blog shows how to embed a dependency inside a plugin, but that's tons more complicated than my simple command line invocation.
What am I doing wrong?
Using windows 10, java 9, maven 3.6.2

What am I doing wrong?
1) Beware when you want to use plugins/libraries not maintained. The source code was not updated from about 8 years. That may have important issues.
2) To know how to use a maven plugin, don't look in the pom declaration. You can find some information in but you will find much more information in the mojo implementation/specification.
But in fact no, you should not even rely on that to understand how to use a plugin.
3) Indeed a Maven plugin may support configurable properties : directly in the pom.xml and even export them for command line usage. But that is not automatic.
But in both cases, that has to be foreseen by the plugin developer and it is generally documented on the plugin or the source repository homepage.
In fact in your case, if you go into the Mojo implementation : AbstractH2Mojo, you can see how the configuration is set.
All properties have default values in the mojo constructor.
protected AbstractH2Mojo() {
super();
final Service tcpService = new Service("tcp", Service.getDefaultPort("tcp"), false, false);
this.setServices(Collections.singletonList(tcpService));
this.setPort(Service.getDefaultPort("tcp"));
this.setShutdownPassword("h2-maven-plugin");
this.setJava(new File(new File(new File(System.getProperty("java.home")), "bin"), "java"));
}
The mojo empty constructor is first invoked, then all setter are invoked on the created instance.
It means that you can override any of these properties defined in that class at runtime by providing the property such as ${artifactIdPrefixWithoutMavenPlugin}.field.
Since the maven plugin is h2-maven-plugin, the prefix to refer is h2.
If you run that :
mvn -X com.edugility:h2-maven-plugin:1.0:spawn -Dh2.port=8084 -Dh2.useSSL=false
You could see in the output :
[DEBUG] Configuring mojo 'com.edugility:h2-maven-plugin:1.0:spawn' with basic configurator -->
[DEBUG] (s) port = 8084
[DEBUG] (s) shutdownHost = localhost
[DEBUG] (s) shutdownPassword = h2-maven-plugin
[DEBUG] (s) useSSL = false
[DEBUG] -- end configuration --
[DEBUG] Process arguments: [/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -cp, /home/david/.m2/repository/com/h2database/h2/1.3.162/h2-1.3.162.jar, org.h2.tools.Server, -tcp, -tcpPassword, h2-maven-plugin, -tcpPort, 8084]
Concerning the h2 jar used, if you still look in the same class, you will see that part that retrieves the jar file from the classpath :
public final File getH2() {
final ProtectionDomain pd = Server.class.getProtectionDomain();
assert pd != null;
final CodeSource cs = pd.getCodeSource();
assert cs != null;
final URL location = cs.getLocation();
assert location != null;
try {
return new File(location.toURI());
} catch (final URISyntaxException wontHappen) {
throw (InternalError)new InternalError().initCause(wontHappen);
}
}
It means that you have no way to change the H2 JAR used : from the command line when you run the plugin or from the plugin declaration in the pom.xml, since no property is defined in the Mojo to achieve that.
if you will change the H2 version, you need to change the version embedded by the plugin. As a starter, you could try to fork the plugin GIT repository, change the h2 dependency used in the pom to match to your requirement and check whether in spite of the gap version, working with that plugin is a possible thing.
Note that you could add a new property of the Mojo to make it completely configurable such as :
mvn ... -Dh2Version=1.4.200
But in that case you will need to retrieve that. For example by performing a request to download the dependency from the m2 central repo for example.
And you should also ensure that only valid ranges of the h2 version are used.

I don't think you'll be able to do that using this particular maven-plugin. Here is another answer for someone that had a similar issue: How to pass parameter to Maven plugin from CLI?.
Basically, the h2Version property is not defined as a user property.
When you start the plugin, using the command that you've mentioned, there is an output for pre-defined configuration properties:
<configuration>
<allowOthers>${h2.allowOthers}</allowOthers>
<baseDirectory>${h2.baseDirectory}</baseDirectory>
<forceShutdown>${h2.forceShutdown}</forceShutdown>
<ifExists>${h2.ifExists}</ifExists>
<java>${h2.java}</java>
<port default-value="9092">${h2.port}</port>
<shutdownAllServers>${h2.shutdownAllServers}</shutdownAllServers>
<shutdownHost default-value="localhost">${h2.shutdownHost}</shutdownHost>
<shutdownPassword default-value="h2-maven-plugin">${h2.shutdownPassword}</shutdownPassword>
<trace>${h2.trace}</trace>
<useSSL>${h2.useSSL}</useSSL>
</configuration>
Only these properties could be defined by the user. For example, changing the running port:
mvn -debug com.edugility:h2-maven-plugin:1.0:spawn -Dport=9090

Configure multiple Jacoco reports for Sonarqube with Maven

I am building a SpringBoot/Maven project. Jacoco is configured to check coverage and creates 3 reports:
from unit tests (surefire) target/jacoco.exec (xml: target/site/jacoco)
from integration tests (failsafe) target/jacoco-it.exec (xml: target/site/jacoco-it)
aggregate (jacoco-aggregate) target/jacoco-aggregate.exec (xml: target/site/jacoco-aggregate)
Without any additional configuration Sonarqube seems to create it's own aggregate:
[INFO] 13:14:27.153 Analysing C:\Users\code\dras-mt\target\jacoco-it.exec
[INFO] 13:14:27.248 Analysing C:\Users\code\dras-mt\target\jacoco.exec
[INFO] 13:14:27.414 Analysing C:\Users\code\dras-mt\target\sonar\jacoco-merged.exec
And it warns about deprecated use of properties:
[DEBUG] 13:14:27.000 Property 'sonar.junit.reportsPath' is deprecated and will be ignored, as property 'sonar.junit.reportPaths' is also set.
(they are not set via my pom.xml)
The problem with the generated report is, that Sonarqube seems to show the aggregated coverage but only counts the unit tests.
My question is how to get a consistent report (coverage matches count tests) and in best case how to export all 3 reports to Sonarqube (Sonarqube's own aggregate could be the 4th).
I tried to use property:
<properties>
....
<sonar.coverage.jacoco.xmlReportPaths>
${project.build.directory}/site/jacoco-aggregate/,${project.build.directory}/site/jacoco/,${project.build.directory}/site/jacoco-it/
</sonar.coverage.jacoco.xmlReportPaths>
</properties>
But this property seems to be completely ignored (i tried also absolute and reletive paths and set via -D and also single path) - so log output (also using -X) does not change.
(first i tried this: https://community.sonarsource.com/t/coverage-test-data-importing-jacoco-coverage-report-in-xml-format/12151)
So how to correctly confige the sonar-maven-plugin (3.7.0.1746) to show the 3 reports?

How to get the next build number in Gradle

Is there any way to get the next version when publishing to a repository in gradle?
For e.g. if I have the version 3.0.1 in my repository I want the published version to be 3.0.2.
ivy has a task for ant named buildnumber which does exactly that:
<project xmlns:ivy="antlib:org.apache.ivy.ant"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<target name="ivyBuildNumber" description="Use ivy get the next build number">
<ivy:buildnumber
resolver="url-chain"
organisation="${ivy.organisation}"
module="${ivy.module}"
revision="${version.base}"/>
<echoproperties prefix="ivy.new."/>
</target>
Is there a way to do so in gradle? if not how can I access ivy tasks from gradle's ant?
In my build.gradle I calling to the ant
ant.importBuild 'build.xml'

I don't think there is support in Gradle, but you can try to use the Ant task.
https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build
Another way to do this is to use some sort of plugin, or customized task for managing the version.
Plugin: https://github.com/researchgate/gradle-release
Custom task: https://www.tikalk.com/devops/increment-version-numbers-in-gradle/

Yes, you can access ivy tasks from the ant script by importing ant's build.xml file to gradle's build.gradle file. Following is the syntax to do so.
ant.importBuild 'build.xml'
Please refer : https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

I recommend you to use ResearchGate release plugin
https://github.com/researchgate/gradle-release
It has a pretty documentation. Easy to read.
Also, check out how I used it in my personal project.
https://github.com/vatolinrp/bitcoin-esb/blob/master/build.gradle
It would be a nice example for you.

After a long work, I managed to do that.
In my build.gradle I added this following code
ant.importBuild 'build.xml'
task getNextBuild(dependsOn : ivyBuildNumber) {
doLast{
def nextVersion = ant.properties['ivy.new.revision']
println nextVersion
}
}
I imported my ant build file, and created a task that calls the ivy buildnumber task.
There is my build.xml
<project xmlns:ivy="antlib:org.apache.ivy.ant">
<target name="ivyBuildNumber">
<path id="ivy.classpath" path="lib/ivy.jar" />
<typedef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpathref="ivy.classpath" />
<ivy:buildnumber
organisation="daniel"
module="hello"/>
<echoproperties prefix="ivy.new."/>
</target>
</project>
Because my IDE (Intellij), didn't have ivy.jar in the content,
I imported the ivy.jar from my root dir (lib/ivy.jar)

For this exact behavior, Ivy buildnumber task can be invoked using pure Gradle without importing the Ant build:
configurations {
antTasks // define a new configuration
}
repositories {
mavenCentral()
}
dependencies {
antTasks("org.apache.ivy:ivy:2.4.0") // add Ivy library to it
}
ext {
// define the Ivy task, using the extra configuration as classpath extension
ant.taskdef(name: "ivyBuildNumber",
classname: "org.apache.ivy.ant.IvyBuildNumber",
classpath: configurations.antTasks.asPath)
ant.ivyBuildNumber(organisation: "daniel", module: "hello")
nextVersion = ant.properties["ivy.new.revision"]
}
task demo {
doLast {
println nextVersion
}
}
In general, Gradle doesn't have any bundled equivalent to Maven Release Plugin, so one has to rely on plugins. One solid plugin is gradle-release by ResearchGate, the other is axion by Allegro Tech. The former is classic Maven-style versioning, the latter takes SCM itself as the only source of truth, eliminating the versioning in the build files. But neither of these plugins does provide the exact requested behavior.
My personal take on the versioning problem was initially to use some plugins. Since I use Bamboo as CI server at work, literally everything I did with release plugins using Gradle crashed on CI server sooner or later. It might have worked for some weeks, but every server update brought some problems. I ended up using SCM-less approach with a simple convention: use branch name as base version, concatenate it with build number (both values are provided by the CI server):
ext {
branch = System.getProperty("branch", "develop")
buildNumber = System.getProperty("buildNumber", "latest")
isRelease = System.getProperty("isRelease", "false").toBoolean()
artifactVersion = "${branch}${(isRelease ? ".$buildNumber" : "-SNAPSHOT")}"
}
CI server then can be set up for executing the following command
./gradlew -DisRelease=true -Dbranch=${git.branch} -DbuildNumber=${build.number} mavenPublish
when 'Release' button is pushed. For example, build 12 of the 3.0 branch will produce version 3.0.12 in the binary repository.
The advantages are:
+ the version comes for free, assuming the branches are named accordingly
+ the auto-incremented build number also comes for free
+ one can easily publish custom revisions
+ no plugins means no problems with Gradle version updates
+ this approach is dead simple and always works
The downsides are:
- additional script tasks are required for tags
- some build numbers will be skipped, obviously (e.g. next version after 3.5.76 can be 3.5.84)

Jenkins job failing because of incorrect parent child pom.xml entries

Below is the issue occurred while building project using Jenkins job, this project is having a parent pom.xml which is defining version of dependencies in it and certainly the SNAPSHOTS etc. which are imported are not required or may be a version clash.
I had a deep look into pom and no unused SNAPSHOT are there in effective pom.
Anyone having idea on what could be the problem, any debugging tips would be really helpful.
Thanks in advance.
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.4.0:java (default-cli) on project script: An exception occured while executing the Java class. null: InvocationTargetException: Effective-pom for 'com.xxx.bss.rm.invoicing.messages:compile:pom:0.5.0-SNAPSHOT' contains SNAPSHOT, failing build. Check any properties and make sure they end in .version if they specifify versions.
Properties in Parent pom
<properties>
<coba.cdac-version>7.1.1</coba.cdac-version>
<coba.businessentity-version>6.3.6</coba.businessentity-version>
<com.xxx.bss.vre.version>2.8.0</com.xxx.bss.vre.version>
<java.oam.version>R3F01</java.oam.version>
<cil.service.version>3.0.1</cil.service.version>
<cil.client.version>5.0.3</cil.client.version>
<cil.messaging.version>1.0.0</cil.messaging.version>
<bss.ctrl.jmx.monitor.version>3.0.1-E002</bss.ctrl.jmx.monitor.version>
<bss.ctrl.version>3.0.2</bss.ctrl.version>
<courier.version>4.1.0</courier.version>
<com.google.code.gson.gson.version>2.3.1</com.google.code.gson.gson.version>
<common.oam.version>1.12.0</common.oam.version>
<com.xxx.bss.ecim.cm.observer.version>0.4.0</com.xxx.bss.ecim.cm.observer.version>
<com.xxx.bss.osgi.srstub.serviceregistrystub.version>2.0.0
</com.xxx.bss.osgi.srstub.serviceregistrystub.version>
<org.osgi.service.event.version>1.3.1</org.osgi.service.event.version>
<commons-configuration.version>1.9</commons-configuration.version>
<com.unboundid-ldapsdk.version>3.0.0</com.unboundid-ldapsdk.version>
<org.apache.ant.version>1.9.7</org.apache.ant.version>
<ngee.oam.version>2.0.3</ngee.oam.version>
<cel-version>3.7.3</cel-version>
<avalon-framework-api-version>4.2.0</avalon-framework-api-version>
<xalan-version>2.7.1</xalan-version>
<xercesImpl-version>2.11.0</xercesImpl-version>
<json-version>20140107</json-version>
<curator-framework-version>2.10.0</curator-framework-version>
<akka.version>2.3.4</akka.version>
<scala.version>2.11</scala.version>
<common.akka.version>1.0.1</common.akka.version>
<cql3-version>2.0.2</cql3-version>
<avro-version>1.7.7</avro-version>
<!-- <trace.services.version>0.7.0</trace.services.version> -->
<javax.servlet.version>2.5.0</javax.servlet.version>
<javax.servlet.servlet-api.version>2.5</javax.servlet.servlet-api.version>
<mock-http-server.version>3.0</mock-http-server.version>
<hector-client.version>3.3.1</hector-client.version>
<commons-io.version>2.4</commons-io.version>
<junitparams.version>1.0.2</junitparams.version>
<activemq.version>5.9.1</activemq.version>
<!-- Changed from 2.6 -->
<jersey.version>2.10.1</jersey.version>
<jersey-media-multipart.version>2.5.1</jersey-media-multipart.version>
<jackson.version>1.9.13</jackson.version>
<!-- Changed from 4.3 -->
<com.eclipsesource.jaxrs.publisher.version>4.1</com.eclipsesource.jaxrs.publisher.version>
<com.eclipsesource.jaxrs.jersey.all.version>2.10.1</com.eclipsesource.jaxrs.jersey.all.version>
<org.glassfish.jersey.containers.version>2.10.1</org.glassfish.jersey.containers.version>
<org.apache.felix.eventadmin.version>1.4.2</org.apache.felix.eventadmin.version>
<uncommons.math.version>1.2.2</uncommons.math.version>
<apache.fop.version>1.0</apache.fop.version>
<javax.inject.version>1</javax.inject.version>
<org.ops4j.pax.exam.version>4.7.0</org.ops4j.pax.exam.version>
<pax.url.version>2.4.7</pax.url.version>
<pax.logging.version>1.8.5</pax.logging.version>
<com.xxx.bss.rm.common.datatypes.version>1.20.0</com.xxx.bss.rm.common.datatypes.version>
<com.xxx.bss.ms.registry.version>2.1.0</com.xxx.bss.ms.registry.version>
<bss.osgi.functioncontrol.version>2.1.0</bss.osgi.functioncontrol.version>
<project.msv.fc.version>2.1.0</project.msv.fc.version>
<charging.rf.core.version>1.35.0</charging.rf.core.version>
<com.xxx.bss.osgi.trace.version>1.0.1</com.xxx.bss.osgi.trace.version>
<cpm.cdac.dataenquirey.version>7.1.3</cpm.cdac.dataenquirey.version>
<cpm.cdac.common.version>7.0.0</cpm.cdac.common.version>
<rmca.cdac.version>23.1.2</rmca.cdac.version>
<com.xxx.bss.integrationtest.utils>0.61.0</com.xxxx.bss.integrationtest.utils>
<jive.common.version>0.0.1-alpha.62</jive.common.version>
<karaf.version>3.0.5</karaf.version>
<sigar.version>1.6.4</sigar.version>
<sigar-osgi.version>1.0.0</sigar-osgi.version>
<org.apache.servicemix.bundles.lucene.version>5.3.1_1</org.apache.servicemix.bundles.lucene.version>
<org.apache.servicemix.bundles.jakarta-regexp.version>1.4_1
</org.apache.servicemix.bundles.jakarta-regexp.version>
<org-apache-xmlgraphics-version>1.7</org-apache-xmlgraphics-version>
<org-apache-xmlgraphics-common-version>1.4</org-apache-xmlgraphics-common-version>
<xalan-serializer-version>2.7.1</xalan-serializer-version>
<xml-apis-version>1.4.01</xml-apis-version>
<xml-apis-ext-version>1.3.04</xml-apis-ext-version>
<avalon-framework-version>4.3.1</avalon-framework-version>
<avalon-logkit-version>2.2.1</avalon-logkit-version>
<caf-utility.version>R3B05</caf-utility.version>
<org.eclipse.jetty.version>8.1.3.v20120416</org.eclipse.jetty.version>
<com.springsource.javax.transaction.version>1.1.0</com.springsource.javax.transaction.version>
<com.springsource.javax.jms.version>1.1.0</com.springsource.javax.jms.version>
<org.eclipse.jetty.orbit.javax.servlet.version>3.0.0.v201112011016
</org.eclipse.jetty.orbit.javax.servlet.version>
<commons-lang3.version>3.4</commons-lang3.version>
<com.thoughtworks.paranamer.version>2.7</com.thoughtworks.paranamer.version>
<org.apache.felix.webconsole.version>4.0.0</org.apache.felix.webconsole.version>
<commons-beanutils.version>1.9.2</commons-beanutils.version>
<common-logging.version>1.1.1</common-logging.version>
<commons-fileupload.version>1.2.2</commons-fileupload.version>
<com.squareup.javapoet.version>1.0.0</com.squareup.javapoet.version>
<commons-csv.version>1.1</commons-csv.version>
<cassandra-driver-core.version>3.0.0-E001</cassandra-driver-core.version>
<io.dropwizard.metrics.metrics-core.version>3.1.0</io.dropwizard.metrics.metrics-core.version>
<commons-collections.version>3.2.1</commons-collections.version>
<org.json-osgi.version>20080701</org.json-osgi.version>
<com.eclipsesource.jaxrs.publisher.version>4.1</com.eclipsesource.jaxrs.publisher.version>
<org.eclipse.equinox.common.version>3.6.100-v20120522-1841</org.eclipse.equinox.common.version>
<org.eclipse.equinox.http.jetty.version>3.0.1-v20121109-203239</org.eclipse.equinox.http.jetty.version>
<org.eclipse.equinox.http.servlet.version>1.1.300-v20120522-1841</org.eclipse.equinox.http.servlet.version>
<org.eclipse.equinox.metatype.version>1.2.0-v20120522-1841</org.eclipse.equinox.metatype.version>
<org.eclipse.osgi.services.version>3.3.100-v20120522-1822</org.eclipse.osgi.services.version>
<io.netty.version>4.0.27.Final</io.netty.version>
<io.netty.netty.version>3.8.3.Final</io.netty.netty.version>
<msg-services.version>1.4.2</msg-services.version>
<msg-gateway.version>1.4.2</msg-gateway.version>
<uk.nominet.dnsjnio.version>1.0.3-E005</uk.nominet.dnsjnio.version>
<com.typesafe.config.version>1.2.1</com.typesafe.config.version>
<protobuf-java.version>2.5.0</protobuf-java.version>
<scalabuff-runtime.version>1.3.7</scalabuff-runtime.version>
<jfree.jfreechart.version>1.0.13</jfree.jfreechart.version>
<jfree.jcommon.version>1.0.16</jfree.jcommon.version>
<joda-time.version>2.7</joda-time.version>
<com.google.guava.version>16.0.1</com.google.guava.version>
<javax.ws.rs-api.version>2.0</javax.ws.rs-api.version>
<snappy-java.version>1.1.0-M4</snappy-java.version>
<ical4j.version>1.0.5.2</ical4j.version>
<org.codehaus.groovyall.version>2.2.0</org.codehaus.groovyall.version>
<javax.annotation-api.version>1.2</javax.annotation-api.version>
<validation-api.version>1.1.0.Final</validation-api.version>
<com.springsource.org.apache.commons.codec.version>1.5.0</com.springsource.org.apache.commons.codec.version>
<org.eclipse.tycho.org.eclipse.osgi.version>3.9.0.v20130529-1710</org.eclipse.tycho.org.eclipse.osgi.version>
<geronimo-jms_1.1_spec.version>1.1.1</geronimo-jms_1.1_spec.version>
<org.simpleframework.simple>5.1.6</org.simpleframework.simple>
<zookeeper-version>3.4.8</zookeeper-version>
<kafka.version>0.9.0.0_1</kafka.version>
<org.osgi.version>4.3.1</org.osgi.version>
<!-- Invoice CLI -->
<core.ui.version>1.3.0</core.ui.version>
<charging.core.clamshell>1.5.0</charging.core.clamshell>
<com.github.fge.json.validator>2.2.6</com.github.fge.json.validator>
<com.github.fge.json.schema.core>1.2.5</com.github.fge.json.schema.core>
<com.googlecode.libphonenumber.libphonenumber>7.2.2</com.googlecode.libphonenumber.libphonenumber>
<com.google.code.findbugs.jsr305>2.0.1</com.google.code.findbugs.jsr305>
<net.sf.jopt-simple.jopt.simple>4.6</net.sf.jopt-simple.jopt.simple>
<com.github.fge.uri.template>0.9</com.github.fge.uri.template>
<com.github.fge.jackson.coreutils>1.8</com.github.fge.jackson.coreutils>
<org.mozilla.rhino>1.7R4</org.mozilla.rhino>
<com.github.fge.msg.simple>1.1</com.github.fge.msg.simple>
<com.fasterxml.jackson.core.jackson.databind>2.6.4</com.fasterxml.jackson.core.jackson.databind>
<com.fasterxml.jackson.core.jackson.annotations>2.6.4</com.fasterxml.jackson.core.jackson.annotations>
<com.fasterxml.jackson.core.jackson.core>2.6.4</com.fasterxml.jackson.core.jackson.core>
<com.github.fge.msg.simple>1.1</com.github.fge.msg.simple>
<com.github.fge.btf>1.2</com.github.fge.btf>
<javax.mail.mailapi>1.4.3</javax.mail.mailapi>
<camunda.version>7.3.0</camunda.version>
<com.h2database.h2.version>1.4.190</com.h2database.h2.version>
<org.mybatis.mybatis.version>3.2.8</org.mybatis.mybatis.version>
<org.glassfish.jersey.connectors.version>2.10.1</org.glassfish.jersey.connectors.version>
<org.apache.httpcomponents.httpclient.version>4.3</org.apache.httpcomponents.httpclient.version>
<org.apache.httpcomponents.httpcore.version>4.3</org.apache.httpcomponents.httpcore.version>
<com.xxx.bss.commonschemas.version>0.3.0</com.xxx.bss.commonschemas.version>
<nl.jqno.equalsverifier.version>1.7.5</nl.jqno.equalsverifier.version>
<org.apache.avro.version>1.7.7</org.apache.avro.version>
<org.apache.felix.scr.version>1.8.2</org.apache.felix.scr.version>
<org.quartz-scheduler.version>2.2.2</org.quartz-scheduler.version>
<c3p0.c3p0-version>0.9.1.2</c3p0.c3p0-version>
<org.codehaus.fabric3.api.commonj-version>1.1.0</org.codehaus.fabric3.api.commonj-version>
<javax.ejb.ejb-api-version>3.0</javax.ejb.ejb-api-version>
<org.apache.servicemix.bundles.quartz.version>2.2.2_1</org.apache.servicemix.bundles.quartz.version>
<cassandra-version>2.2.6-E001</cassandra-version>
<com.xxx.bss.rm.cpm.cdac.translation.version>7.0.0</com.xxx.bss.rm.cpm.cdac.translation.version>
<com.googlecode.json-simple.version>1.1.1</com.googlecode.json-simple.version>
<metrics.version>1.0.0</metrics.version>
</properties>
Content in child pom
<parent>
<groupId>com.xxxx.xxx.xx.xxx.top</groupId>
<artifactId>compile</artifactId>
<version>0.6.0-SNAPSHOT</version>
<relativePath />
</parent>
<groupId>com.xxxx.xxx.xx.xxx.messages</groupId>
<artifactId>compile</artifactId>
<version>0.5.0-SNAPSHOT</version>
<name>${project.groupId}.${project.artifactId}</name>
I don't know whether it helps to some extent..
Goals
<goals>clean install -pl script exec:java -Dscript.buildName="invoicing-release" -Dscript.releaseRepository="proj-invoicing-release-local" -Dscript.stagingRepository="proj-invoicing-staging-local" -Dscript.gitWorkArea="${WORKSPACE}/.gitworkarea" -Dscript.repository="${WORKSPACE}/.scriptrepository" -Dscript.mavenSettings="${MAVEN_SETTINGS}" -B -e -Dsurefire.useFile=false --settings ${MAVEN_SETTINGS} -Dorg.ops4j.pax.url.mvn.settings=${MAVEN_SETTINGS} -Dmaven.repo.local=${MAVEN_REPOSITORY} -Dorg.ops4j.pax.url.mvn.localRepository=${MAVEN_REPOSITORY} -Djava.io.tmpdir=${WS_TMP}</goals>

It looks like you are invoking custom Java program performing a variant of mvn release. By convention it is not allowed to release a project which has SNAPSHOT dependencies, i.e. dependencies with version ending on 'SNAPSHOT'. However, your child pom.xml refers to dependency with version 0.5.0-SNAPSHOT. That needs to be changed to a fix version (one not ending on SNAPSHOT), again by convention this would be 0.5.0. It is also likely that the version 0.5.0 of your dependency is not available yet and therefore you need to perform the release for that project beforehand.
The convention for the versioning of maven projects is as follows. During the development are jars versioned with xx-SNAPSHOT. For the xx-SNAPSHOT-versioned jars it is allowed to produce a new jar containing new features and version the new jar with the same xx-SNAPSHOT version (i.e., replace one given xx-SNAPSHOT jar with a new one). Then once the development is finished the project will be released and the jar will be versioned with fixed version xx (no SNAPSHOT anymore). From then on the jar versioned with fixed version xx will not be replaced anymore. Of course if jar versioned xx is not allowed to change then also all of his dependencies must not change, i.e. all dependencies must be in fixed version.
Aparently the program started from the jenkins job checks if the convention is adhered to and after finding the dependency versioned 0.5.0-SNAPSHOT it requires that this is fixed first.
Btw there is probably an error in the artifactId of your dependency - compile is usually a value for the <scope> element.

How disable sql-maven-plugin file copy to temp folder?

Here is a piece of plugin configuration:
<configuration>
<srcFiles>
<srcFile>src${file.separator}integration-test${file.separator}resources${file.separator}sql${file.separator}schema.sql</srcFile>
</srcFiles>
</configuration>
Everything works, but I see in log:
[INFO] --- sql-maven-plugin:1.5:execute (create-tables) # smsfinance-server ---
[INFO] Executing file: C:\Users\User\AppData\Local\Temp\schema.915861870sql
Is there a way to disable copying?

No, this is not possible at the moment.
Reading from the source code of version 1.5, the SQL Maven Plugin is copying the sources files to a temporary directory to handle filtering, even when filtering is disabled. Filtering is enabled with the attribute enableFiltering.
You could create an issue at their GitHub page to disable copying of the file when filtering is disabled (which is the default).

Workaround
For cases when sql files is placed on ssd disk, you can specify tmp dir on ssd - just add -Djava.io.tmpdir=/ssd-drive/tmp to maven command line. It does not disable copying, but spead up sql execution process.