<project ...><parent>...</parent><properties>...</properties><dependencies>...</dependencies><build><plugins>...</plugins></build><repositories>...</repositories><pluginRepositories><pluginRepository><id>spring-libs-milestone</id><url>https://repo.spring.io/libs-milestone</url></pluginRepository></pluginRepositories></project>
In Maven we have 3 types of repositories1. Central Repository2. Remote Repository3. Local RepositoryCentral repository is maintained by Apache organizationEvery company will maintain their own remote repository (Ex: Nexus, JFrog)Local repository will be created in our system (Location : C://users/<uname>/.m2)
<repositories><repository> <id>id</id> <url>jfrong-repo-url/</url> </repository> </repositories>
<project ...><parent>...</parent><properties>...</properties><dependencies>...</dependencies><build><plugins>...</plugins></build><repositories><repository><id>spring-libs-milestone</id><url>https://repo.spring.io/libs-milestone</url></repository></repositories><pluginRepositories>...</pluginRepositories></project>
<plugin> <groupId>org.graalvm.buildtools</groupId> <artifactId>native-maven-plugin</artifactId> </plugin>
<profiles><profile><id>native</id><build><plugins><plugin><groupId>org.graalvm.buildtools</groupId><artifactId>native-maven-plugin</artifactId><executions><execution><id>build-native</id><goals><goal>compile-no-fork</goal></goals><phase>package</phase></execution></executions></plugin></plugins></build></profile></profiles>
./mvnw clean package -Pnative
./mvnw clean package -Dpackaging=native-image
If you have not installed it to your own machine, you also have an option to use a Docker container that has GraalVM and the native image extension installed by default. You can use the following command for that:./mvnw package -Pnative -Dquarkus.native.container-build=trueIt might take some time to finish compilation, especially in the docker container, but after a while you should have a native executable named code-with-quarkus-1.0.0.-SNAPSHOT-runner in your target folder.
./mvnw package -Pnative -Dquarkus.native.container-build=true
<profile>
<id>native</id>
<activation>
<property>
<name>native</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<extensions>true</extensions>
<executions>
<execution>
<id>build-native</id>
<goals>
<goal>build</goal>
</goals>
<phase>package</phase>
</execution>
<execution>
<id>release-native</id>
<goals>
<goal>release</goal>
</goals>
<phase>release</phase>
</execution>
</executions>
<configuration>
<imageName>${appName}-${project.version}</imageName>
<mainClass>${mainClass}</mainClass>
<buildArgs>
<buildArg>--allow-incomplete-classpath</buildArg>
<buildArg>--no-fallback</buildArg>
<buildArg>-H:+ReportExceptionStackTraces</buildArg>
<buildArg>--verbose</buildArg>
</buildArgs>
</configuration>
</plugin>
</plugins>
</build>
</profile>./mvnw -B --file pom.xml -Pnative package
When you run the resulting application, the application will report the Class files it is unable to find...You can then add them to the reflect-config.json in the resources/META-INF/native-image folder of your project.And you specify the configuration in native-image.properties for GraalVM native-image-plugin to refer the reflect-config.json while building the native image.-H=ReflectionConfigurationResources=${.}/reflect-config.json
[
{
"name": "io.jsonwebtoken.impl.crypto.MacProvider",
"allDeclaredConstructors": true,
"allPublicConstructors": true,
"allDeclaredMethods": true,
"allPublicMethods": true,
"allDeclaredClasses": true,
"allPublicClasses": true
},
...
]<buildArg>--allow-incomplete-classpath</buildArg>
An alternative quick fix could be the option --allow-incomplete-classpath. This ensures that the possible linking errors are shifted from build time to run time.
ERROR: Classes that should be initialized at run time got initialized during image building:…
The most classes are initialized at build time and GraalVM tries to find out what can be initialized at build time and which classes must be initialized at run time. This error can be fixed with the parameter --initialize-at-run-time. This parameter will force to initialize this class at runtime. Another way to force to initialize a class during build is to use the parameter --initialize-at-build-time.
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>
<buildArg>--initialize-at-build-time=my.build.package</buildArg>
<buildArg>--initialize-at-build-time=my.other.build.package.SpecificClass</buildArg>
<buildArg>--initialize-at-run-time=my.run.package</buildArg>
<buildArg>--initialize-at-run-time=my.other.run.package.SpecificClass</buildArg>
</buildArgs>
</configuration><plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>
<buildArg>--initialize-at-build-time=org.apache.commons.logging.LogFactory,org.apache.commons.logging.LogFactoryService,org.slf4j.MDC,ch.qos.logback.core.pattern.parser.Parser,ch.qos.logback.core.util.Loader,ch.qos.logback.core.util.StatusPrinter,org.slf4j.impl.StaticLoggerBinder,org.slf4j.LoggerFactory,ch.qos.logback.classic.Logger,ch.qos.logback.core.spi.AppenderAttachableImpl,ch.qos.logback.core.status.StatusBase,ch.qos.logback.classic.Level,ch.qos.logback.core.status.InfoStatus,ch.qos.logback.classic.PatternLayout,ch.qos.logback.core.CoreConstants</buildArg>
<buildArg>-H:+ReportExceptionStackTraces</buildArg>
</buildArgs>
<jvmArgs>
<arg>-Xmx8g</arg>
<arg>-Xms8g</arg>
</jvmArgs>
</configuration>
<executions>
<execution>
<id>build-native</id>
<goals>
<goal>compile-no-fork</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin><plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<jvmArgs>
<arg>-Xmx8g</arg>
<arg>-Xms8g</arg>
</jvmArgs>
</configuration>
<executions>
<execution>
<id>build-native</id>
<goals>
<goal>compile-no-fork</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>So far Mockito is not supported for tests. This can bring up problems for a high number of existing applications and result in big test refactoring projects. There are two possible ways to get it running: either exclude all mocking tests or simply skip native tests with setting the configuration skipNativeTests to true:
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<skipNativeTests>true</skipNativeTests>
</configuration><plugin><groupId>com.rudikershaw.gitbuildhook</groupId><artifactId>git-build-hook-maven-plugin</artifactId><version>3.1.0</version><configuration><installHooks><commit-msg>hooks/commit-msg</commit-msg><pre-commit>hooks/pre-commit</pre-commit></installHooks></configuration><executions><execution><goals><goal>install</goal></goals></execution></executions></plugin>
#!/usr/bin/env bash mvn spotless:apply
mvn install
<plugin><groupId>org.codehaus.mojo</groupId><artifactId>animal-sniffer-maven-plugin</artifactId><version>1.16</version><configuration><signature><groupId>org.codehaus.mojo.signature</groupId><artifactId>java16</artifactId><version>1.0</version></signature></configuration><executions><execution><id>animal-sniffer</id><phase>verify</phase><goals><goal>check</goal></goals></execution></executions></plugin>
Goal Name Descriptionk8s:build Containerize your application into an imagek8s:push Push the Image built to a container registryk8s:resource Generate Kubernetes Manifestsk8s:deploy Apply these manifests on top of Kubernetesk8s:log View logs of your application running in Kubernetes Clusterk8s:debug Debug your application running into Kubernetes
mvn k8s:build# If docker daemon is not available mvn k8s:build -Djkube.build.strategy=jib
To have Kubernetes Maven plugin push our built image to Docker Hub, we need to supply the image name to the Kubernetes Maven plugin, by adding jkube.generator.name property in pom.xml ...By doing so, the Kubernetes Maven plugin will get the image name from spring-boot.build-image.imageName property.By default, the Kubernetes Maven plugin always pushes images tagged as the latest to the remote repository. Since our built image is tagged with version rather than latest, we will need to disable this feature. Add the following jkube.skip.tag property with true value to pom.xml to disable Kubernetes Maven plugin overriding our tag in the supplied image name.
<properties>
<java.version>11</java.version>
<spring-boot.build-image.imageName>andylke/${project.artifactId}:${project.version}</spring-boot.build-image.imageName>
<jkube.generator.name>${spring-boot.build-image.imageName}</jkube.generator.name>
<jkube.skip.tag>true</jkube.skip.tag>
</properties>mvnw ^
-Djkube.docker.username={docker-hub.username} ^
-Djkube.docker.password={docker-hub.password} ^
k8s:push<plugin>
<groupId>org.eclipse.jkube</groupId>
<artifactId>kubernetes-maven-plugin</artifactId>
<version>${jkube.version}</version>
<configuration>
<images>
<image>
<name>quay.io/rohankanojia/helloapp:${project.version}</name>
<alias>hello-world</alias>
<build>
<from>openjdk:latest</from>
<cmd>java -jar maven/${project.artifactId}-${project.version}.jar</cmd>
</build>
</image>
</images>
</configuration>
</plugin>mvn k8s:push mvn k8s:push -Djkube.build.strategy=jib
Kubernetes Maven plugin can either generate1. based on opinionated defaults,2. based on the configuration provided in XML config3. resource templates in src/main/jkube directory.
By default, Kubernetes Maven plugin generates a Deployment with a single replica and Service resource that is only reachable from within the cluster, known as ClusterIP. To create a network load balancer service with an externally accessible IP address, we need to change the default Service type to LoadBalancer. Add a jkube.enricher.jkube-service.type property with value LoadBalancer as follows.<jkube.enricher.jkube-service.type>LoadBalancer</jkube.enricher.jkube-service.type>Run the following command to invoke the Kubernetes Maven plugin to generate Kubernetes manifests.mvnw k8s:resource
These Kubernetes manifests are all generated in target/classes/META-INF/jkube/kubernetes directory. You should find your generated jkube-app-deployment.yml and jkube-app-service.yml files
mvn k8s:resource
Kubernetes Maven plugin will combine all generated Kubernetes manifests from the target/classes/META-INF/jkube/kubernetes directory into a single Kubernetes manifest file, target/classes/META-INF/jkube/kubernetes.yml. This consolidated Kubernetes manifest will be used when we invoke the apply goal in Kubernetes Maven plugin.Run the following command to apply our generated Kubernetes manifest to our locally connected Kubernetes cluster.mvnw k8s:applyYour Kubernetes manifest being applied successfully to the Kubernetes cluster does not guarantee the defined Kubernetes resources will start successfully. Always verify the state of your applied resources.Run the following command to list all resources in your local Kubernetes cluster with labels app=jkube-app.kubectl get all -l app=jkube-appIf all goes well, you should have a running Pod, a service with an external IP address, a deployment, and ReplicaSet.
mvn k8s:deploy mvn k8s:undeploy # Inspect logs mvn k8s:log mvn k8s:log -Djkube.log.follow=false
mvn k8s:debug mvn k8s:debug -Djkube.debug.port=8000
<plugin><groupId>org.eclipse.jkube</groupId><artifactId>kubernetes-maven-plugin</artifactId><version>${jkube.version}</version><configuration><remoteDevelopment><remoteServices><remoteService><hostname>service1</hostname> <!-- Name of Service --><port>8080</port> <!-- Service port --><localPort>8081</localPort> <!-- Local Port where to expose --></remoteService><remoteService><hostname>service2</hostname> <!-- Name of Service --><port>8080</port> <!-- Service Port --><localPort>8082</localPort> <!-- Local Port where to expose --></remoteService></remoteServices></remoteDevelopment></configuration></plugin>
mvn k8s:remote-dev
<plugin><groupId>io.confluent</groupId><artifactId>kafka-schema-registry-maven-plugin</artifactId><version>${confluent.version}</version><configuration><schemaRegistryUrls><param>http://localhost:8081</param></schemaRegistryUrls><subjects><send-payment-value>${project.basedir}/src/main/resources/avro/send_payment.avsc</send-payment-value><payment-sent-value>${project.basedir}/src/main/resources/avro/payment_sent.avsc</payment-sent-value></subjects></configuration><goals><goal>register</goal></goals></plugin>
mvn schema-registry:register
mvn spotless:check
In contrast to check goal the apply goal is not verbose at all. It just simply tells us if formatting was done or not. The main change we can observe are the changes in source code.
<plugin>
<groupId>com.diffplug.spotless</groupId>
<artifactId>spotless-maven-plugin</artifactId>
<executions>
<execution>
<id>format</id>
<phase>process-sources</phase>
<goals>
<goal>check</goal>
<goal>apply</goal>
</goals>
</execution>
</executions>
</plugin>
mvn spotless:apply
<java>
<toggleOffOn/>
<importOrder/>
<removeUnusedImports/>
<palantirJavaFormat>
<version>2.27.0</version>
</palantirJavaFormat>
<indent>
<spaces>true</spaces>
<spacesPerTab>4</spacesPerTab>
</indent>
<formatAnnotations/>
</java><plugin><groupId>com.diffplug.spotless</groupId> <artifactId>spotless-maven-plugin</artifactId> <version>2.9.0</version> <configuration> <java> <includes> <include>src/main/java/**/*.java</include> <include>src/test/java/**/*.java</include> </includes> <googleJavaFormat> <version>1.15.0</version> <style>GOOGLE</style> </googleJavaFormat> </java> </configuration> </plugin>
Configurations like palantirJavaFormat and prettier have their own sections.
For example, you can configure prettier to use a separate configuration file like this:
<prettier>
<version>2.4.1</version>
<configFile>${project.basedir}/.prettierrc</configFile>
</prettier><plugin>
<groupId>com.diffplug.spotless</groupId>
<artifactId>spotless-maven-plugin</artifactId>
<version>2.25.0</version>
<configuration>
<formats>
<!-- prettier with java-plugin -->
<format>
<includes>
<include>src/*/java/**/*.java</include>
</includes>
<prettier>
<devDependencies>
<prettier>2.0.5</prettier>
<prettier-plugin-java>0.8.0</prettier-plugin-java>
</devDependencies>
<config>
<tabWidth>4</tabWidth>
<parser>java</parser>
</config>
</prettier>
</format>
</formats>
</configuration>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin><markdown>
<includes> <!-- You have to set the target manually -->
<include>**/*.md</include>
</includes>
<flexmark/>
</markdown><pom>
<includes>
<include>pom.xml</include>
</includes>
<sortPom>
<encoding>UTF-8</encoding>
<keepBlankLines>true</keepBlankLines>
<nrOfIndentSpace>4</nrOfIndentSpace>
<indentBlankLines>false</indentBlankLines>
<indentSchemaLocation>true</indentSchemaLocation>
<expandEmptyElements>false</expandEmptyElements>
<sortProperties>true</sortProperties>
</sortPom>
</pom><plugin>
<groupId>com.diffplug.spotless</groupId>
<artifactId>spotless-maven-plugin</artifactId>
<configuration>
<java>
<toggleOffOn/>
<importOrder/>
<removeUnusedImports/>
<palantirJavaFormat>
<version>2.27.0</version>
</palantirJavaFormat>
<indent>
<spaces>true</spaces>
<spacesPerTab>4</spacesPerTab>
</indent>
<formatAnnotations/>
</java>
<markdown>
<includes>
<include>**/*.md</include>
</includes>
<flexmark/>
</markdown>
<pom>
<includes>
<include>pom.xml</include>
</includes>
<sortPom>
<encoding>UTF-8</encoding>
<keepBlankLines>true</keepBlankLines>
<nrOfIndentSpace>4</nrOfIndentSpace>
<indentBlankLines>false</indentBlankLines>
<indentSchemaLocation>true</indentSchemaLocation>
<expandEmptyElements>false</expandEmptyElements>
<sortProperties>true</sortProperties>
</sortPom>
</pom>
</configuration>
<executions>
<execution>
<id>format</id>
<goals>
<goal>check</goal>
<goal>apply</goal>
</goals>
<phase>process-sources</phase>
</execution>
</executions>
</plugin>%JDK_HOME%\bin%MAVEN_HOME%\bin%GRADLE_HOME%\bin
Jib is a Maven plugin and a Gradle plugin for building container images for your Java applications. It allows you to build container images directly from your Java code, without needing to manually create a Dockerfile. Jib handles all the steps of packaging your application into a container image, including building the application code, adding files to the image, and configuring the image to run the application.
<build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.8.0</version>
<configuration>
<to>
<image>gcr.io/my-project/my-image</image>
</to>
</configuration>
</plugin>
</plugins>
</build>
> mvn jib:buildJib builds optimized Docker OCI images for Java applications. It is an open source project developed by Google. Similar to builldpacks, no Dockerfile needs to be created.To use Jib, you need to add a maven plugin into your pom.xml file as follows:<plugin><groupId>com.google.cloud.tools</groupId><artifactId>jib-maven-plugin</artifactId><version>2.6.0</version></plugin>To build the Docker image run the command:./mvnw compile jib:dockerBuild -Dimage=rest-server-jib:0.0.1Command to run the image:docker run -it -p8080:8080 rest-server-jib:0.0.1
mvn clean install jib:dockerBuild -Djib.to.image=spring-docker-demo:v1
<profile>
<id>jib-push-to-local</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<from>
<image>openjdk:8</image>
</from>
<container>
<ports>
<port>8080</port>
</ports>
<format>OCI</format>
</container>
</configuration>
<executions>
<execution>
<id>push-custom-tag</id>
<phase>package</phase>
<configuration>
<to>
<image>betulsahinn/${app.image.name}:${app.image.tag}</image>
</to>
</configuration>
<goals>
<goal>dockerBuild</goal>
</goals>
</execution>
<execution>
<id>push-latest-tag</id>
<phase>package</phase>
<configuration>
<to>
<image>betulsahinn/${app.image.name}:latest</image>
</to>
</configuration>
<goals>
<goal>dockerBuild</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>mvn clean install jib:dockerBuild -P jib-push-to-local -Dapp.image.tag=v2
<!-- for set JAR file inside the container -->
<containerizingMode>packaged</containerizingMode>
<container>
<jvmFlags> <!-- jvm flags -->
<jvmFlag>-Xms512m</jvmFlag>
<jvmFlag>-Xdebug</jvmFlag>
</jvmFlags>
<ports> <!-- allow port when container running -->
<port>8080</port>
</ports>
<format>Docker</format>
</container>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<from>
<image>openjdk:8</image>
</from>
<container>
<ports>
<port>8080</port>
</ports>
<format>OCI</format>
</container>
</configuration>
</plugin><plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.3.1</version>
<configuration>
<from>
<image>openjdk:17</image>
</from>
</configuration>
</plugin><from>
<image>openjdk:17-oracle</image>
<platforms>
<platform>
<architecture>amd64</architecture>
<os>linux</os>
</platform>
<platform>
<architecture>arm64</architecture>
<os>linux</os>
</platform>
</platforms>
</from><plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.8.0</version>
<configuration>
<to>
<image>gcr.io/my-project/my-image</image>
</to>
</configuration>
</plugin>to>
<image>docker.io/abdalrhmanalkraien/energy-tech</image>
<tags>
<tag>${image.version}</tag>
<tag>latest</tag>
</tags>
<auth>
<username>myUserName</username>
<password>MyPassword</password>
</auth>
</to><profile>
<id>jib-push-to-dockerhub</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.5.2</version>
<configuration>...</configuration>
<executions>
<execution>
<id>push-custom-tag</id>
<phase>package</phase>
<configuration>
<to>
<image>docker.io/betulsahinn/${app.image.name}:${app.image.tag}</image>
</to>
</configuration>
<goals>
<goal>build</goal>
</goals>
</execution>
<execution>
<id>push-latest-tag</id>
<phase>package</phase>
<configuration>
<to>
<image>docker.io/betulsahinn/${app.image.name}:latest</image>
</to>
</configuration>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>mvn clean install -P jib-push-to-dockerhub -Dapp.image.tag=v2
A software bill of materials, often abbreviated as SBOM, is a list of all software components used in an application. The SBOM is made up of third-party open-source libraries, vendor-provided packages, and first-party artifacts built by the organization. You can basically see it as the full list of ingredients for your applications.
But be careful to not confuse an SBOM with Maven’s Bill Of Materials (BOM). In Maven, a BOM is a special kind of POM file where we can centralize dependencies for an application. In most cases, these dependencies work well together and should be used as a set, like we see in BOMs used in Spring.
An SBOM is something you create next to your application, so any user or client has a uniform way to find out what your application is using under the hood.
CycloneDX is a SBOM standard from the OWASP foundation designed for application security contexts and supply chain component analysis, providing an inventory of all first-party and third-party software components. The specification is rich and extends beyond software libraries to standards such as software as a service bill of materials (SaaSBOM), Vulnerability Exploitability Exchange (VEX), and more. The CycloneDX project provides standards in XML, JSON, and Protocol Buffers, as well as a large collection of official and community-supported tools that create or interoperate with the standard.
./spdx-sbom-generator
<plugin><groupId>org.cyclonedx</groupId><artifactId>cyclonedx-maven-plugin</artifactId><version>2.7.1</version><executions><execution><phase>package</phase><goals><goal>makeAggregateBom</goal></goals></execution></executions><configuration><projectType>library</projectType><schemaVersion>1.4</schemaVersion><includeBomSerialNumber>true</includeBomSerialNumber><includeCompileScope>true</includeCompileScope><includeProvidedScope>true</includeProvidedScope><includeRuntimeScope>true</includeRuntimeScope><includeSystemScope>true</includeSystemScope><includeTestScope>false</includeTestScope><includeLicenseText>false</includeLicenseText><outputReactorProjects>true</outputReactorProjects><outputFormat>all</outputFormat><outputName>CycloneDX-Sbom</outputName></configuration></plugin>
You can configure the CycloneDX plugin in different ways. In this case, I bound the makeAggregateBom goal of the plugin to the package phase of Maven. After my JAR is created, the plugin will create an SBOM, taking aggregation into account. It excludes the test dependencies and releases the SBOM in both XML and JSON format in my target folder.
The Software Package Data Exchange (SPDX) is a Linux Foundation collaborative project that provides an open standard for communicating software bill of material information, including provenance, licensing, security, and other related information. The SPDX specification is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.
<plugin>
<groupId>org.spdx</groupId>
<artifactId>spdx-maven-plugin</artifactId>
<version>0.6.1</version>
<executions>
<execution>
<id>build-spdx</id>
<phase>package</phase>
<goals>
<goal>createSPDX</goal>
</goals>
</execution>
</executions>
</plugin>