We Keep Coding

Remove the dependency on Python while building RPM using rpm-maven-plugin

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>
...

How to generate python protobuf from java maven project

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.

Enable exec-maven-plugin while executing jar through java command

I am using exec-maven-plugin to execute a shell script.
<executions>
<execution>
<id>exec-ui-install</id>
<phase>generate-sources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>bash</executable>
<arguments>
<argument>${basedir}/ui-build.sh</argument>
</arguments>
<skip>${exec.skip}</skip>
</configuration>
</execution>
</executions>
I dont want this to run during build time (as i don't need to run it during build and i am building it from windows). So i am using a parameter named exec.skip and with its help i am able to skip it.
After building jar and moving it to Linux env i am using java command
Ex: java -cp : javaclass
to run the jar. During this i need to execute "exec-maven-plugin" which was disabled during build mode. How do i pass "exec.skip=true" through java command so that i can run plugin.

You cannot do it.
The maven configuration of a project is used during the build of the project.
Once the artifact/component is constructed, you don't interact any longer with maven.
In your case, you should build your component with the suitable configuration parameters before moving it to linux.
Using a Maven profile with this specific configuration that is launched by a continuous integration tool could ease the task and make it reliable.

JaCoCo Offline Instrumentaion and Integration Test Coverage Reports

I have been trying to implement JaCoCo offline code coverage in a JBoss server using an instrumented EAR for deployment and the jacococagent.jar in order to track code coverage of external integration testing running against said JBoss.
I have been following guides such as these:
http://www.eclemma.org/jacoco/trunk/doc/offline.html
http://automationrhapsody.com/code-coverage-with-jacoco-offline-instrumentation-with-maven/
I feel I am pretty close as everything SEEMS to be working, however, when I load the coverage report up in eclipse's EclEmma plugin, it reports as 0 coverage for everything (which I know is wrong).
Here's my setup:
Here's the maven plugin configuration:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<configuration>
<!-- <destFile>${sonar.jacoco.reportPath}</destFile> -->
<append>true</append>
<excludes>
<exclude>**/dao/**/*Dao*</exclude>
<exclude>**/dao/**/*DAO*</exclude>
<exclude>**/dao/**/*Vo*</exclude>
<exclude>**/dao/**/*VO*</exclude>
<exclude>**/ui/**/*</exclude>
<exclude>**/*Vo.*</exclude>
<exclude>**/*VO.*</exclude>
<exclude>**/test/**/*</exclude>
<exclude>**/tester/**/*</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>pre-unit-test</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
</configuration>
</execution>
<execution>
<id>unit-test-report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>${sonar.jacoco.reportPath}</dataFile>
</configuration>
</execution>
<execution>
<id>jacoco-instrument</id>
<phase>test</phase>
<goals>
<goal>instrument</goal>
</goals>
<configuration>
<skip>${jacoco.skip.instrument}</skip>
<!-- <skip>false</skip> -->
</configuration>
</execution>
</executions>
</plugin>
Here's my jacoco-agent.properties file:
destfile=/stage/live_integration_jacoco.exec
output=file
dumponexit=true
append=true
I'm bundling the JaCoCo Agent JARs right inside the EAR as these dependencies (the second one is just what jacocoagent.jar is labelled as in our repository):
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.agent</artifactId>
<version>${jacoco.version}</version>
</dependency>
<dependency>
<groupId>org.jacoco.build</groupId>
<artifactId>org.jacoco.jacocoagent</artifactId>
<version>${jacoco.version}</version>
</dependency>
Here's my process:
I run this on the project: mvn clean install -U -Djacoco.skip.instrument=false
And that generates my instrumented EAR artifact. I have verified that the classes in there are indeed instrumented by JaCoCo by decompiling a few of them.
I take that EAR that has instrumented code, the jacococagent.jar included in it, and the jacoco-agent.popreties file included as well and deploy that to JBoss. JBoss starts just fine (it used to get ClassNotFound exception before I started bundling jacocoagent.jar in it directly).
The "/stage/live_integration_jacoco.exec" file is created at this point with a size of '0'.
I run some tests on and against the server, even some manual testing, then stop the application.
The "/stage/live_integration_jacoco.exec" file now has data (30-60kb of data so far in my observations).
I import that exec file into eclipse and it loads without any errors and shows the classes in the project, however it reports 0 coverage on everything.
Well, I'm not sure what else to try at this point.
Does anyone have some thoughts on how to get it correctly generating the coverage report in my situation?
Thanks!

I suspect that classes deployed on server are compiled with Oracle Java compiler, while classes in Eclipse are compiled with Eclipse Java compiler, and hence JaCoCo can't associate them since they differ. To confirm this - you can try to generate report using the exec file that you try to import, but outside of Eclipse using Ant or Maven. And make sure that you execute generation of report on original (non instrumented) classes, otherwise they also won't match.

Maven, run a java method or script before war is about to be built

I am thinking of using a template engine to generate the web.xml and other things.
Is there as way to to run a java file or a script before the maven install command? Or before the war is generated.
I am not sure what the phase should be, but basically before anyone else looks at the web.xml so I can touch it to make a new valid one.

You can use the exec-maven-plugin to run either a program/script (using the exec goal) or a Java program (using the java goal).
The phase immediately before package is prepare-package (see the Default lifecycle in the Lifecycle Reference), so you could use that. But you might prefer to generate the web.xml earlier in the lifecycle (even as early as generate-resources).
Putting these together, you might try something like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.3.2</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>your_packaging_script</executable>
<!-- optional -->
<workingDirectory>/tmp</workingDirectory>
<arguments>
<argument>--some-option</argument>
</arguments>
</configuration>
</plugin>
Alternatively, you might consider writing your own plugin, especially if you think the idea would be useful for more than one project.