Pass dockerPublisher maven properties over command line in spring-boot:build-image - spring-boot

I want to integrate the spring boot maven plugins capability to build and publish an OCI Image to a remote Repository
My Goal
I want to use the following plugin configuration:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<name>${docker.image.prefix}/${project.artifactId}:${project.version}</name>
</image>
</configuration>
<executions>
<execution>
<goals>
<goal>build-image</goal>
</goals>
</execution>
</executions>
</plugin>
And now I want to pass the docker.publishRegistry variables by command line.
What I've tried so far
I've tried to pass the parameter with the -Ddocker.publishRegistry.username property but that didn't work.
When you take a look at the source code of the plugin Docker has no Parameter property assigned to it:
/**
* Alias for {#link Image#publish} to support configuration via command-line property.
*/
#Parameter(property = "spring-boot.build-image.publish", readonly = true)
Boolean publish;
/**
* Docker configuration options.
* #since 2.4.0
*/
#Parameter
private Docker docker;
https://github.com/spring-projects/spring-boot/blob/82b90d57496ba85be316b9eb88a36d81f2cc9baa/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/main/java/org/springframework/boot/maven/BuildImageMojo.java#L159
So I guess it is not possible to define this parameter by command line or is it?
Current Workaround
Currently I'm defining the properties by global maven properties and reuse them in the docker scope.
My pom.xml:
<properties>
<docker-registry>https://example.org</docker-registry>
<docker-registry-username>username</docker-registry-username>
<docker-registry-username>password</docker-registry-username>
</properties>
<!-- ... -->
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<name>${docker.image.prefix}/${project.artifactId}:${project.version}</name>
</image>
<docker>
<publishRegistry>
<username>${docker-registry-username}</username>
<password>${docker-registry-password}</password>
<url>${docker-registry}</url>
</publishRegistry>
</docker>
</configuration>
<executions>
<execution>
<goals>
<goal>build-image</goal>
</goals>
</execution>
</executions>
</plugin>
And I'm building with:
./mvnw -B -s \
-Dspring-boot.build-image.publish=true \
-Ddocker-registry-username="$USERNAME" \
-Ddocker-registry-password="$PASSWORD" \
-Ddocker-registry="$REGISTRY" \
clean deploy

I have not the exact solution to you question: "passing publishRegistry parameters on the command line", but If I may, I have another workaround that shields you from exposing your credential in the pom.xml.
What i have done is to put the parameters and credential in a profile in my .m2/settings.xml like this:
<profiles>
<profile>
<id>docker-io-credentials</id>
<properties>
<docker-reg>docker.io</docker-reg>
<docker-reg.user>your-user-name</docker-reg.user>
<docker-reg.pwd>your-token-or-passwd</docker-reg.pwd>
<docker-reg.url>${docker-reg}/library/${docker-reg.user}</docker-reg.url>
</properties>
</profile>
</profiles>
Then on the command-line you can simply pass the profile's name to merge the credential to the current build.
mvn clean install -Pdocker-io-credentials

You can define placeholders in the spring-boot plugin's configuration, which refer to environment variables. This will be slightly less complex, so like
...
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>main.Class</mainClass>
<image>
<name>registry-url/library/image-name:${project.version}</name>
</image>
<docker>
<publishRegistry>
<username>docker-user</username>
<password>${env.docker_registry_password}</password>
<url>https://registry-url/v1/</url>
<email>user#example.com</email>
</publishRegistry>
</docker>
</configuration>
...
See more on this topic here: https://www.baeldung.com/maven-env-variables

Just to mention that the Spring team is aware and did not consider this a bug but rather a documentation issue: https://github.com/spring-projects/spring-boot/issues/31024#issuecomment-1127905504
Very similar to what #twobiers suggested in his workaround:
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<docker>
<publishRegistry>
<url>${docker.publishRegistry.url}</url>
<username>${docker.publishRegistry.username}</username>
<password>${docker.publishRegistry.password}</password>
</publishRegistry>
</docker>
</configuration>
and then I build (and publish to Github Packages Registry) my project with:
./mvnw spring-boot:build-image \
-Ddocker.publishRegistry.username=${{ github.actor }} \
-Ddocker.publishRegistry.password=${{ secrets.GITHUB_TOKEN }} \
-Ddocker.publishRegistry.url=ghcr.io \
-Dspring-boot.build-image.publish=true \
-Dspring-boot.build-image.imageName="ghcr.io/${{ github.repository }}:latest" \
-DskipTests

Related

Maven: How to exclude a plugin with a custom flag

I have a plugin in my Spring Boot projects pom.xml which I would like the option of sometimes disabling when running mvn clean install.
Is there a configuration I could add to my pom.xml which would create a custom flag e.g. exc, which when invoked like so mvn clean install -D exc would build the jar, without that plugin.
For clarity, here is the plugin I would like to disable via a maven flag:
<plugin>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-maven-plugin</artifactId>
<version>${springdoc-openapi-maven.version}</version>
<configuration>
<apiDocsUrl>http://localhost:XXXX/v3/api-docs</apiDocsUrl>
<outputDir>${project.basedir}/openapi</outputDir>
</configuration>
<executions>
<execution>
<phase>integration-test</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
You can add <springdoc.skip>true</springdoc.skip> to your <properties> section.
Then you can activate the plugin by mvn clean install -Dspringdoc.skip=false
You can use profile to do that. Adding something like :
<profile>
<id>no-springdoc</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build><plugins>
<plugin>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-maven-plugin</artifactId>
<version>${springdoc-openapi-maven.version}</version>
<configuration><skip>true</skip><configuration>
</plugin>
</plugins></build>
</profile>
and then building with mvn ... -P no-springdoc should build without the plugin.
https://maven.apache.org/guides/introduction/introduction-to-profiles.html

How to embed CA-certificates with spring-boot:build-image?

I need to add self-signed certificates to a spring-boot docker image using spring-boot:build-image and paketo-buildpacks/ca-certificates but couldn't get it working.
So:
where to put the certificates to add?
in which format?
how to define paketo-buildpacks/ca-certificates bindings?
should any additional argument be provided to mvn spring-boot:build-image?
What I tried with no success so far:
update pom.xml spring-boot-maven-plugin:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<bindings>
<binding>${basedir}/bindings/ca-certificates:/platform/bindings/ca-certificates</binding>
</bindings>
</image>
</configuration>
<executions>
<execution>
<goals>
<goal>build-image</goal>
</goals>
</execution>
</executions>
</plugin>
from ${basedir} folder:
mkdir bindings
mkdir bindings/ca-certificates
echo "ca-certificates" > bindings/ca-certificates/type
cp ~/.ssh/mycert.pem bindings/ca-certificates/
mvn spring-boot:build-image
Edit: moved image bindings configuration directly under boot-plugin (rather than inside a specific execution) as suggested by #nick-valanos and solved the problem.
I got it. Maven configuration above is for maven package target, not spring-boot:build-image.
Here is the complete procedure:
create bindings/ca-certificates folder at maven project root and add to it:
type file containing just ca-certificates
CA certificatates you want to be embedded (in PEM format)
in pom.xml, add a build-image execution to spring-boot-maven-plugin with ${basedir}/bindings/ca-certificates:/platform/bindings/ca-certificates image binding as configured in my question
run mvn clean package
I kind of had the same issue and I found your post really helpful. After a bit playing around, I found that your configuration would also work with spring-boot:build-image with the following alterations:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<bindings>
<binding>${basedir}/bindings/ca-certificates:/platform/bindings/ca-certificates</binding>
</bindings>
</image>
</configuration>
</plugin>
As you can see, I added the <configuration> immediately after <plugin>. That way, it seems that it is parceable by spring-boot:build-image

Duplication in maven: are profiles additive to project, or do they replace declared items?

Provided you have the following defined in your POM.xml:
<project>
<!-- ... -->
<build>
<plugins>
<plugin>
<artifactId>plugin-X</artifactId>
<!-- plugin config -->
</plugin>
<plugins>
</build>
<profiles>
<profile>
<id>foo</id>
<build>
<plugins>
<plugin>
<artifactId>plugin-X</artifactId>
<!-- plugin config -->
</plugin>
<plugins>
</build>
<profile>
</profiles>
</project>
If the plugin config for plugin-X is exactly the same for profile foo as it is for a build without a selected profile, do you have to redeclare the plugin at all on the profile level? If so, do you also have to redeclare all config settings for it?
If you declared plugin-Y in project.profile.build.plugins instead of plugin-X (but left it declared on the project level), which plugins would be run when you run mvn -P foo? Only plugin-Y, or also plugin-X?
More generally speaking, are profiles additive to what is declared on the project level, or do they override it? (If they are additive, how do you "remove" entities that were declared on a project level when you run a build profile and don't want them for that specific profile?)
I know profile configuration gets inherited from parent pom files ("from either the build/plugins or pluginManagement sections of the parent") with options "merge", "append", and "override". I think what I really want to know is: how does maven behave when the same/similar information is defined on the project and profile levels in the same pom file...
This isn't a full answer, but another piece of the puzzle - in addition to my earlier comments, and maven's Guide to Configuring Plug-ins.
Given the following pom.xml file:
</profiles>
<properties>
<foo>main</foo>
<bar>main</bar>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<configuration>
<target>
<echo>${foo}</echo>
<echo>${bar}</echo>
<echo>${baz}</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>p</id>
<properties>
<bar>prof</bar>
<baz>prof</baz>
</properties>
</profile>
</profiles>
</project>
When I run mvn validate, I get the following output:
[echo] main
[echo] main
[echo] ${baz}
Running mvn validate -P p however yields:
[echo] main
[echo] prof
[echo] prof
That means that properties at least are merged, appending new items and replacing those that are redefined.
Also, if I add another plugin to the profile (such as surefire), it will execute when running the profile with mvn <phase> -P p, so the profile inherits antrun and adds surefire. Plugin re-definitions however replace the original; adding
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<configuration>
<target>
<echo>Tada!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
only prints Tada!, but no longer the original antrun output (even when changing the new addition's phase to initialize. Adding <inherited>true</inherited> to any of the two plugin definitions doesn't make a difference. The behaviour might be plugin-specific, though.

How can I specify the path in tomee-maven-plugin such that both deploy and undeploy works?

I'm trying to build a pom.xml to handle the deployment and undeployment to a remote TomEE (PluME 7.0.3) server. However, I cannot figure out the correct value to use in the path configuration tag. Here's a working plugin configuration for deploying my application (full-blown EAR, for educational purposes) to the remote TomEE:
<build>
<plugins>
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>7.0.3</version>
<configuration>
<context>someear</context>
<tomeeClassifier>plus</tomeeClassifier>
<tomeeHost>192.168.100.100</tomeeHost>
<debugPort>8000</debugPort>
<tomeeAjpPort>8009</tomeeAjpPort>
<tomeeHttpPort>8080</tomeeHttpPort>
<tomeeShutdownPort>8005</tomeeShutdownPort>
<path>target/someear-1.0-SNAPSHOT.ear</path>
<useBinaries>true</useBinaries>
</configuration>
</plugin>
</plugins>
</build>
Whereas to undeploy, I would have to configure the plugin like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>7.0.3</version>
<configuration>
<context>someear</context>
<tomeeClassifier>plus</tomeeClassifier>
<tomeeHost>192.168.100.100</tomeeHost>
<debugPort>8000</debugPort>
<tomeeAjpPort>8009</tomeeAjpPort>
<tomeeHttpPort>8080</tomeeHttpPort>
<tomeeShutdownPort>8005</tomeeShutdownPort>
<path>someear-1.0-SNAPSHOT</path>
<useBinaries>true</useBinaries>
</configuration>
</plugin>
</plugins>
</build>
Notice the difference in the path configuration. From the command line, this behaves similarly; when the path tag in the pom.xml is omitted, I can deploy and undeploy like this:
mvn tomee:deploy -Dtomee-plugin.archive=target/someear-1.0-SNAPSHOT.ear
mvn tomee:undeploy -Dtomee-plugin.archive=someear-1.0-SNAPSHOT
Has anybody experienced the same behaviour, and found a way to mitigate this? I'd like to have both deploy and undeploy configured completely in the pom.xml without specifying additional parameters when calling mvn. But, as of now, I cannot do that, since tomee:deploy seems to expect a different path than tomee:undeploy.
EDIT
Ok, based on #Old School's edited answer, I can do something like this:
<profiles>
<profile>
<id>deploy</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<my-tomee-maven-plugin-path>target/someear-1.0-SNAPSHOT.ear</tomee-maven-plugin-path>
</properties>
</profile>
<profile>
<id>undeploy</id>
<properties>
<my-tomee-maven-plugin-path>someear-1.0-SNAPSHOT</tomee-maven-plugin-path>
</properties>
</profile>
</profiles>
Then, specify path in tomee-maven-plugin's configuration section like this:
...
<path>${my-tomee-maven-plugin-path}</path>
...
Then, execute maven like this:
mvn tomee:deploy
mvn tomee:undeploy -Pundeploy
Which I consider more convenient than specifying some -D parameters at execution time (YMMV).
However, the perfect solution in my opinion would be if you could configure path in tomee-maven-plugin's configuration such that both tomee:deploy and tomee:undeploy work without further ado.
EDIT2
I discovered another possibility without profiles which I was seemingly unable to find before (based on: http://tomee-openejb.979440.n4.nabble.com/Deployment-to-TomEE-7-0-0-using-tomee-maven-plugin-error-Cannot-open-input-stream-to-server-tp4679142p4679282.html):
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>7.0.3</version>
<configuration>
<context>${project.artifactId}</context>
<tomeeClassifier>plus</tomeeClassifier>
<context>someear</context>
<tomeeClassifier>plus</tomeeClassifier>
<tomeeHost>192.168.100.100</tomeeHost>
<debugPort>8000</debugPort>
<tomeeAjpPort>8009</tomeeAjpPort>
<tomeeHttpPort>8080</tomeeHttpPort>
<tomeeShutdownPort>8005</tomeeShutdownPort>
<!-- no <path> tag -->
<useBinaries>true</useBinaries>
</configuration>
<executions>
<execution>
<id>deploy-it</id>
<phase>none</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<path>target/someear-1.0-SNAPSHOT.ear</path>
</configuration>
</execution>
<execution>
<id>undeploy-it</id>
<phase>none</phase>
<goals>
<goal>undeploy</goal>
</goals>
<configuration>
<path>someear-1.0-SNAPSHOT</path>
</configuration>
</execution>
</executions>
</plugin>
Usage:
mvn tomee:deploy#deploy-it
mvn tomee:undeploy#undeploy-it
I use glassfish, not tomcat, but I think the same principles apply here. In GF, deploy requires the full path and the undeploy requires only the package name. For example, glassfish goes something like:
asadmin deploy C:\Projects\Java\helloworld\helloworld.war
and
asadmin undeploy helloworld
There is no path required on undeploy because the file is on the server and once you name it, glassfish/tomcat knows where it is.
EDIT based off comments: My apologies for the glassfish stuff, I wasn't paying attention to you mentioning tomcat and I've edited a bit to reflect that somewhat.
I do understand now, I think, what you're looking for. Check out:
Maven Resource Filtering
It's another SO answer where he does a fantastic job of explaining exactly what you're looking for, I think. I hope that works.

Maven and adding JARs to system scope

I have a JAR in my Android project and I want it to be added to final APK.
Okay, here I go:
<dependency>
<groupId>com.loopj.android.http</groupId>
<artifactId>android-async-http</artifactId>
<version>1.3.2</version>
<type>jar</type>
<scope>system</scope>
<systemPath>${project.basedir}/libs/android-async-http-1.3.2.jar</systemPath>
</dependency>
But when I am running mvn package I am getting a warning:
[WARNING] Some problems were encountered while building the effective model for **apk:1.0
[WARNING] 'dependencies.dependency.systemPath' for com.loopj.android.http:android-async-http:jar should not point at files within the project directory, ${project.basedir}/libs/android-async-http-1.3.2.jar will be unresolvable by dependent projects # line 36, column 25
And in the final APK there are no JARs.
How do I fix that?
I don't know the real reason but Maven pushes developers to install all libraries (custom too) into some maven repositories, so scope:system is not well liked, A simple workaround is to use maven-install-plugin
follow the usage:
write your dependency in this way
<dependency>
<groupId>com.mylib</groupId>
<artifactId>mylib-core</artifactId>
<version>0.0.1</version>
</dependency>
then, add maven-install-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>install-external</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/mylib-core-0.0.1.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.mylib</groupId>
<artifactId>mylib-core</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
pay attention to phase:clean, to install your custom library into your repository, you have to run mvn clean and then mvn install
You will need to add the jar to your local maven repository. Alternatively (better option) specify the proper repository (if one exists) so it can be automatically downloaded by maven
In either case, remove the <systemPath> tag from the dependency
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
Try this.
System scope was only designed to deal with 'system' files; files sitting in some fixed location. Files in /usr/lib, or ${java.home} (e.g. tools.jar). It wasn't designed to support miscellaneous .jar files in your project.
The authors intentionally refused to make the pathname expansions work right for that to discourage you. As a result, in the short term you can use install:install-file to install into the local repo, and then some day use a repo manager to share.
Try this configuration. It worked for me:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<warSourceDirectory>mywebRoot</warSourceDirectory>
<warSourceExcludes>source\**,build\**,dist\**,WEB-INF\lib\*,
WEB-INF\classes\**,build.*
</warSourceExcludes>
<webXml>myproject/source/deploiement/web.xml</webXml>
<webResources>
<resource>
<directory>mywebRoot/WEB-INF/lib</directory>
<targetPath>WEB-INF/lib</targetPath>
<includes>
<include>mySystemJar1.jar.jar</include>
<include>mySystemJar2.jar</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
Use a repository manager and install this kind of jars into it. That solves your problems at all and for all computers in your network.
mvn install:install-file -DgroupId=com.paic.maven -DartifactId=tplconfig-maven-plugin -Dversion=1.0 -Dpackaging=jar -Dfile=tplconfig-maven-plugin-1.0.jar -DgeneratePom=true
Install the jar to local repository.
Thanks to Ging3r i got solution:
follow these steps:
don't use in dependency tag. Use following in dependencies tag in pom.xml file::
<dependency>
<groupId>com.netsuite.suitetalk.proxy.v2019_1</groupId>
<artifactId>suitetalk-axis-proxy-v2019_1</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.netsuite.suitetalk.client.v2019_1</groupId>
<artifactId>suitetalk-client-v2019_1</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>com.netsuite.suitetalk.client.common</groupId>
<artifactId>suitetalk-client-common</artifactId>
<version>1.0.0</version>
</dependency>
use following code in plugins tag in pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>suitetalk-proxy</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-axis-proxy-v2019_1-1.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.proxy.v2019_1</groupId>
<artifactId>suitetalk-axis-proxy-v2019_1</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
<execution>
<id>suitetalk-client</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-client-v2019_1-2.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.client.v2019_1</groupId>
<artifactId>suitetalk-client-v2019_1</artifactId>
<version>2.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
<execution>
<id>suitetalk-client-common</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-client-common-1.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.client.common</groupId>
<artifactId>suitetalk-client-common</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
I am including 3 jars from lib folder:
Finally, use mvn clean and then mvn install or 'mvn clean install' and just run jar file from target folder or the path where install(see mvn install log):
java -jar abc.jar
note: Remember one thing if you are working at jenkins then first use mvn clean and then mvn clean install command work for you because with previous code mvn clean install command store cache for dependency.
Following this thread I was able to configure the install plugin to load my custom jar, but the plugin was not seeing my configuration when running a mvn install
I'm using the base maven-install-plugin:2.5.2 using the maven:3.6.3-jdk-8 docker image.
I don't fully understand this note in the documentation (at the end of the section), but it seems that you can give the phase goal an execution id forcing it to use your configuration:
Note: Configurations inside the element used to differ from those that are outside in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command line the execution id for direct plugin goal invocation. Hence if you want to run the above plugin and it's specific execution1's configuration from the command-line, you can execute:
mvn myqyeryplugin:queryMojo#execution1
My final working docker command:
docker run -it --rm --name parser -v "$(shell pwd)":/usr/src/parser -w /usr/src/parser maven:3.6.3-jdk-8 mvn -X install:install-file#install-my-jar-file
Where install-my-jar-file is my executions id <execution><id>install-my-jar-file</id>...

Resources