Creating RPM as a package for your software? Use Maven to generate the RPM using the details shared in this post. Let’s look into the steps and guidelines to create RPM via Maven
Maven POM Changes
<dependency> <groupId>org.codehaus.mojo</groupId> <artifactId>rpm-maven-plugin</artifactId> <version>2.2.0</version> <scope>provided</scope> </dependency>
Specifies the parent location of RPM installation
<prefix>BASEDIR</prefix> <mapping> <directory>/CONFIGDIR</directory> </mapping>
Problem: relative path attribute was not working
Solution: full directory path in the mapping like shown below
<prefix>BASEDIR</prefix> <mapping> <directory>BASEDIR/config</directory> </mapping>
Change Log File
Change log maintains a record of changes being made to the package
You can go through link to understand more about the mapping attributes.
Attributes username and groupname were retained to match the production value.
If QA has a different values for username and groupname, it was modified in post installation scripts
<mapping> <directory>BASEDIR/FOLDERNAME</directory> <configuration>true</configuration> <filemode>PERMISSION</filemode> <username>USERNAME</username> <groupname>GROUPNAME</groupname> <sources> <source> <location>src/main/FOLDER</location> </source> <source> <location>src/main/FOLDER</location> </source> </sources> </mapping>
Local testing using maven
mvn clean package
Every time run with clean option, we have noticed at times that only package results in stale files.
Check spec file of your project.
We checked /target/rpm/project/SPECS/PROJECT.spec file
Check if permissions to users and groups are reflecting correctly and in sync with mappings of pom.xml.
List all the files present inside rpm.
Migrating from .tar to RPM
Follow these steps to change your packaging from tar to RPM
- Compare the lib folder in RPM with the tar (current package) lib contents.
- Check dependency sets in package.xml and based on the differences in previous step, include the same rules as applicable into mappings section in pom.xml.
- Compare the lib folder in RPM with the current production lib contents
To create the lib files
tar xf PROJECT.tar
ls -1 PROJECT/lib/ | sort > PROD
rpm -qlp | grep lib | cut -d / -f6 | sort > BUILD
diff -u BUILD PROD
NOTE: + file in Production, – file in current branch
Open eclipse and follow below steps.
- Open pom.xml
- Navigate to dependency hierarchy and search for -plexis-utils. Here you need to find which plugin has compiled plexis-utils-3.0.8.jar. For us, it was maven-surefire-report-plugin.
- In the search tab, type your jar name ex:plexis-utils, this will display all the jars starting with plexis-utils.
- Check which dependency has compiled this plexis-utils-3.0.8.jar.
- After you find the dependency, go to pom.xml and add plexis-utils in the excluded section as shown below:
<dependency> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-report-plugin</artifactId> <version>2.17</version> <scope>provided</scope> <exclusions> <exclusion> <groupId>com.google.code.findbugs</groupId> <artifactId>jsr305</artifactId> </exclusion> <exclusion> <groupId>org.codehaus.plexus</groupId> <artifactId>plexus-utils</artifactId> </exclusion> </exclusions> </dependency>
Installation of RPM
- Command to check if RPM is installed
yum list or
The above commands lists the installed packages for the particular project.
- check the target folder if all files are present and check permissions, owner, group for the same.
This command will list all the subdirectories inside the project deployment folder with all the files describing timestamp, permissions, owner, and group.
- Ensure latest configuration changes are reflected
- You can add some test statements in your files, rebuild the package and check using step 3 command if latest changes are getting reflected.
- Rebuild the project again as is. Check if files are modified. No files should be modified as project is rebuilt as is without any modifications
- Revert the test changes done and rebuild the project again. Again follow the same steps for verification as mentioned in first point.
You can go through link which explains RPM behavior for various scenarios related to configuration changes
- prefix does not work and entire folder path should be given for every folder created by RPM
- changelog added to RPM was not picked up by version
- Multiple class binding issues related to slf4j jars.
- The diff between RPM lib contents and production lib contents could be more.
Problem Statement: j-units are failing
Root cause: multiple class binding issues with slf4j
Solution: add below exclusion under rpm-maven dependency
<dependency> <groupId>org.codehaus.mojo</groupId> <artifactId>rpm-maven-plugin</artifactId> <version>2.1</version> <scope>provided</scope> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> </exclusion> </exclusions> </dependency>