I'm using rpm-maven-plugin to build an rpm as a part of my mvn build which later will be installed in a docker image that doesn't have Python. Python is not being used in the project as well. But for some reason, the generated spec file has the line
Requires: python >= 2.6
I tried putting in
<autoRequires>no</autoRequires>
<autoProvides>no</autoProvides>
but doesn't work as well. This is causing the docker build to fail as the rpm install fails because of missing dependency. How do I remove the dependency on python?
Following is the extract from my pom.xml
...
<version.rpm-maven-plugin>2.2.0</version.rpm-maven-plugin>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>rpm-maven-plugin</artifactId>
<executions>
<execution>
<id>generate-rpm</id>
<phase>package</phase>
<goals>
<goal>rpm</goal>
</goals>
</execution>
</executions>
<configuration>
<group>XXX</group>
<vendor>XXX</vendor>
<copyTo>
target/${install.package.name}-${project.version}.rpm
</copyTo>
<targetOS>linux</targetOS>
<autoRequires>no</autoRequires>
<autoProvides>no</autoProvides>
<mappings>
...
</mappings>
<preinstallScriptlet>
<scriptFile>${basedir}/src/main/package/control/preinst</scriptFile>
<fileEncoding>utf-8</fileEncoding>
</preinstallScriptlet>
<postinstallScriptlet>
<scriptFile>${basedir}/src/main/package/control/postinst</scriptFile>
<fileEncoding>utf-8</fileEncoding>
</postinstallScriptlet>
<preremoveScriptlet>
<scriptFile>${basedir}/src/main/package/control/prerm</scriptFile>
<fileEncoding>utf-8</fileEncoding>
</preremoveScriptlet>
<postremoveScriptlet>
<scriptFile>${basedir}/src/main/package/control/postrm</scriptFile>
<fileEncoding>utf-8</fileEncoding>
</postremoveScriptlet>
<cleanScriptlet>
<script>rm -rf ${project.build.directory}/rpm/buildroot</script>
</cleanScriptlet>
</configuration>
</plugin>
maven version: 3.5.4.
target docker image runs bare-bones SLES linux with just what is required and doesn't have Python.
Got it working by manually overriding the requires section
...
<autoRequires>no</autoRequires>
<autoProvides>no</autoProvides>
<requires>
<require>java-11-openjdk-headless</require>
</requires>
...
Related
Is it possible to force any maven plugin to execute with VM arguments when I do mvn clean install?
More context
I have an old project that I try to mirgate to java 11. During this migration I had trouble with wadl-client-plugin and JAXB showing this error.
schema_reference: Failed to read schema document '...', because 'file' access is not allowed due to restriction set by the accessExternalSchema property.
When I run it like mvn clean install -Djavax.xml.accessExternalSchema=all it works. I need to include somehow -Djavax.xml.accessExternalSchema=all to the plugin execution when I run mvn clean install. I've checked wadl-client-plugin's docs and don't see anything about it. Is it possible to do it somehow in general way? Configuring local JVM is not an option neither as I cannot do it at all machines.
I finally found an answer here
properties-maven-plugin inside my pom did the trick.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<id>set-additional-system-properties</id>
<goals>
<goal>set-system-properties</goal>
</goals>
</execution>
</executions>
<configuration>
<properties>
<property>
<name>javax.xml.accessExternalSchema</name>
<value>all</value>
</property>
</properties>
<outputFile/>
</configuration>
</plugin>
I have created a Spring Boot java application (REST Services) which uses Tomcat internally as web server on Windows machine using Eclipse as IDE. It uses JDK 1.8 & Maven as build system. Here I create jar file (Run as Maven Install ) and then invoke that jar file from command prompt in my windows machine. I test these REST services using POSTMAN on my Windows machine.
Now I have to get it working on an Linux machine which does not have UI. Can you please help me how to achieve same on Linux machine and how to get those dependencies on Linux machine.
first, make sure your Linux server have Java installed. Best match your local java version.
second, make use of maven plugin to generate a shell script which can kick off this project.
Below is an example
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>1.10</version>
<!-- bind to package phase -->
<executions>
<execution>
<id>make-appassembly</id>
<phase>package</phase>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- set alternative assemble directory -->
<assembleDirectory>${project.build.directory}/${project.artifactId}-${project.version}
</assembleDirectory>
<environmentSetupFileName>envSetup.sh</environmentSetupFileName>
<includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
<repositoryLayout>flat</repositoryLayout>
<repositoryName>lib</repositoryName>
<platforms>
<!-- <platform>windows</platform> -->
<platform>unix</platform>
</platforms>
<!-- Extra JVM arguments that will be included in the bin scripts -->
<extraJvmArguments>-Dlog4j.configuration=file:$BASEDIR/etc/log4j.properties
-Dapplication.properties=file:$BASEDIR/etc/XXX.properties
-Xms2048m
-Xmx12288m -server -showversion -XX:+UseConcMarkSweepGC
-DXXX.log.dir=XXX
-DXXX.app.id=XXX
</extraJvmArguments>
<programs>
<program>
<mainClass>com.xxx.App</mainClass>
<name>xxx.sh</name>
</program></programs>
</configuration>
</plugin>
I've created a simple Micronaut application using
mn create-app app_name --build maven
with a JDK 11 in case that matters.
This creates a maven project which compiles fine, but includes a Dockerfile like this:
FROM adoptopenjdk/openjdk11-openj9:jdk-11.0.1.13-alpine-slim
COPY target/app_name*.jar app_name.jar
EXPOSE 8080
CMD java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dcom.sun.management.jmxremote -noverify ${JAVA_OPTS} -jar app_name.jar
However, there is no docker build included in the Maven AFAICT.
So I included this
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>${dockerfile-maven-version}</version>
<executions>
<execution>
<id>default</id>
<goals>
<goal>build</goal>
<goal>push</goal>
</goals>
</execution>
</executions>
<configuration>
<repository>dockerUser/app_name</repository>
<tag>${project.version}</tag>
<buildArgs>
<JAR_FILE>${project.build.finalName}.jar</JAR_FILE>
</buildArgs>
</configuration>
</plugin>
which does manage to build a docker image, but not without manual intervention. The reason is that upon mvn package, three jars get created in target/:
app_name-0.1.jar
app_name-0.1-shaded.jar
original-app_name-0.1.jar
which makes the docker target fail with
When using COPY with more than one source file, the destination must be a directory and end with a /
That message does make sense because all the jars match the COPY source pattern in the Dockerfile.
Right now, I just delete the other two jars (original and shaded) and run the docker target on its own, but that's only fine as long as I work in local manual mode.
Am I missing something or is this an oversight on the Micronaut project creation?
I can't help you with the micronaut configuration, unfortunately. However, if the purpose is to copy the main jar file and the unknown version suffix is the cause of the wildcard being used while copying, a finalName element can be added to the pom.xml in order to strip the version info from the name of the JAR file:
<build>
<finalName>app_name</finalName>
</build>
Am I missing something or is this an oversight on the Micronaut
project creation?
The latter.
If you file an issue at https://github.com/micronaut-projects/micronaut-profiles/issues we can get it straightened out.
Relevant files:
https://github.com/micronaut-projects/micronaut-profiles/blob/c391ef02b5ca087bbdec79f80b129240b29cc246/service/skeleton/maven-build/Dockerfile
https://github.com/micronaut-projects/micronaut-profiles/blob/c391ef02b5ca087bbdec79f80b129240b29cc246/service/skeleton/gradle-build/Dockerfile
Thanks for the input.
I have maven project in which I have defined various .proto files whose corresponding java files are generated through maven plugin. This generated files would be used for implementation [rpc - server implementation], but I want this to be consumed by python client.
Hence need python equivalent to these proto files.
One way is to manually run python protobuf command to these .proto files and generate code, but this would be too manual work. I am looking for some other alternative.
Any help would be appreciated.
You could automate your manual command b running it from Maven. Take a look at the exec-maven-plugin plugin.
You need to add something like that to the plugins part of your pom.xml:
<plugin>
<artifactId>exec-maven-plugin</artifactId>
<groupId>org.codehaus.mojo</groupId>
<executions>
<execution>
<id>Stuff I want done</id>
<phase>generate-sources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>path/stuff.sh</executable>
</configuration>
</execution>
</executions>
</plugin>
Adapt the phase and the script you want to run.
Worked by adding execution goal as "compile-python" for protobuf-maven-plugin (link) in pom file.
I am trying to implement semantic versioning in our project. I tested maven semver plugin but that didn't help me so please don't ask me why. I finally ended up using maven groovy. It works like a charm, however, when I install or deploy the maven project the version in repository is the variable name.
This is despite the fact that all the artefacts and jar files are packaged with correct version.
So please look at my pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mytest.test</groupId>
<artifactId>test-tag</artifactId>
<version>${revision}</version>
<description>Test</description>
<properties>
<ChangeType>TO_BE_SET</ChangeType>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<providerSelection>2.0</providerSelection>
<properties>
<script>git describe --abbrev=0 --tags</script>
</properties>
<source>
def tagIt = 'git tag -a vXXXX -m "Auto tagged"'
def changeType = project.properties.ChangeType
def command = project.properties.script
def process = command.execute()
process.waitFor()
def describe = process.in.text.trim()
println "Setting revision to: " + describe
if(!describe.startsWith("v")) {
describe = "1.0.1"
} else {
describe = describe.substring(1)
}
project.properties.setProperty('revision', describe)
</source>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>none</phase>
</execution>
<execution>
<id>default-testCompile</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>default-testResources</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>default-jar</id>
<phase>package</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>default-test</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
the version is ${revision} a variable name that is being set in groovy script. What groovy code does is getting the last tag from GIT and and then set it to the property 'revision'.
The final jar file has the correct version extracted but when installed into repository, the folder name and jar name are like:
m2\repository\com\mytest\test\test-tag\${revision}\test-tag-${revision}.jar
I tried to default 'revision' to a value using:
<properties>
<revision>1.0.1</revision>
</properties>
but then groovy code setting the value has no effect.
I also tried different phase for the maven groovy plugin, no luck. Have I missed anything? Can anyone please help me on this?
I'd like to mention that as vatbub and StefanHeimberg mentioned I can use versions:set to set the version but this requires me to do an extra commit to GIT which I am trying to avoid, wondering if I can achieve this by writing a maven plugin instead?
With Maven you can set the version at build time with
mvn versions:set -DnewVersion=${bamboo.inject.version}
as #vatbub already commented in your question.
In addition to this i wrote a Shell script that can be used in build pipeline to generate the version according to the maven project version and add the build number from the build server.
https://gist.github.com/StefanHeimberg/c19d7665e8df087845c036fe8b88c4f2
The Script reads the maven project version, add a the build number and writes a text file with all the new numbers that can be used.
The next step is to inject this text file in the Build Pipeline and call the versions plugin as stated above
pom.xml:
something like
<project>
<groupId>ch.stefanheimberg.example</groupId>
<artifactId>your-awesome-app</artifactId>
<version>5.1.2-SNAPSHOT</version>
</project>
or
<project>
<groupId>ch.stefanheimberg.example</groupId>
<artifactId>your-awesome-app</artifactId>
<version>5.1-SNAPSHOT</version>
</project>
Step 1:
./generate_version_txt.sh ${bamboo.buildNumber}
Step 2:
Inject generated version.txt in the build system that all the properties can be used in all tasks / plugins, etc...
In my case Bamboo CI ready the version.txt file and declares the content of the file as environment variables under the bamboo.inject. prefix.
For example ${bamboo.inject.long_version}
Step 3:
Update Maven Project version
mvn versions:set -DnewVersion=${bamboo.inject.version}
Step 4:
Run Maven Build
mvn clean verify
Step 5:
Run Docker build
for example use it also as docker tag version. etc...
docker build --build-arg version=${bamboo.inject.version} --tag your-awesome-app:${bamboo.inject.version} .
Example Dockerfile:
FROM jboss/wildlfy
ARG version
ADD target/your-awesome-app-${version}.war /opt/jboss/wildfly/standalone/deployments/
I know that can be a problem / not possible in your case with the groovy script. but perhaps it is an other view at your problem. and possibly also another solution for it.
(sorry for my english. but i hope it is understandable what i mean)
I ran into a similar problem and ended up using the maven flatten plugin to ensure that all variables are removed from the POMs before being deployed. This remove all references to the string ${revision} and replace by the actual value at build time, without interfering with the original POMs.