Skip to content

Packages

Jump to bottom
Simon Paulger edited this page Mar 29, 2015 · 7 revisions

The plugin allows the configuration to define multiple RPM packages.

Packages are declared using multiple package XML tags within the packages tag of the plugins configuration:

    ...
    <configuration>
        ...
        <packages>
            <package>
                ...
            </package>
            
            <package>
                ...
            </package>
            
            <package>
                ...
            </package>
        </packages>
        ...
    </configuration>
    ...

Each package declaration contains further XML declarations to select the files for inclusion and customise the packages generated.

Each RPM package will be generated in order of appearance and will be attached as a primary or secondary artefact to the project. Attaching artefacts as primary or secondary artefacts allows them to be used in later stages of the Maven build lifecycle, such as the deployment phase.

Primary artefacts

Maven projects normally produce a primary artefact. This is based on the packaging type of the project and Maven supports the types jar, ear, war, pom by default using Maven's own plugins.

Additional packaging types can be defined and the plugin doe this be defining the rpm packaging type.

If a project is declared with an rpm packaging type, and the RPM package name and version parameters match the project artifactId and version parameters, then the artefact will be attached to the Maven project as a primary artefact.

If the name and version RPM parameters are not provided, then they will default to the project artifactId and version. This means all you have to do to attach an RPM package as a primary artefact of the project is specify a packaging type of rpm. Note that this means that you can only ever add a single RPM package as a primary artefact. If you're generating multiple packages, then any additional packages that will require a different RPM name and/or version will be attached as a secondary artefact.

<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    
    <groupId>com.example</groupId>
    <artifactId>my-project</artifactId>
    <version>1.0</version>
    <packaging>rpm</packaging>
    
    <build>
        <plugins>
            <plugin>
                <groupId>uk.co.codezen</groupId>
                <artifactId>redlinerpm-maven-plugin</artifactId>
                <version>1.0</version>
                <extensions>true</extensions>
                
                <configuration>
                    <packages>
                        <package>
                            ...
                        </package>
                    </packages>
                </configuration>
            </plugin>
        </plugins>
    </build>
 </project>

Secondary artefacts

If you are in the circumstance whereby you cannot or do not want to set a packaging type of rpm, an RPM package generated will become a secondary artefact. Secondary artefacts are generated when the packaging type is not rpm (with a matching artifactId & version), and when the attach XML tag for a package is declared as true. By attach tag will always default to true, unless you override this by hand.

Note that a secondary artefact does not require the extensions XML tag to be applied, which only serves to inform Maven that the plugin provides additional extensions to Maven (in the plugins case, a packaging type).

For example, lets say you want to package your webapp as a Java WAR, but also want to package the web app in to an RPM file.

<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    
    <groupId>com.example</groupId>
    <artifactId>my-project</artifactId>
    <version>1.0</version>
    <packaging>war</packaging>
    
    <build>
        <plugins>
            <plugin>
                <groupId>uk.co.codezen</groupId>
                <artifactId>redlinerpm-maven-plugin</artifactId>
                <version>1.0</version>
                
                <configuration>
                    <packages>
                        <package>
                            ...
                        </package>
                    </packages>
                </configuration>
            </plugin>
        </plugins>
    </build>
 </project>

Preventing attachment of artefacts to the project

If the attach flag is set to false, the artefact will not be attached to the project as a secondary artefact. It will still be generated however, which can be useful if you want to use it later in the build process.

<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    
    <groupId>com.example</groupId>
    <artifactId>my-project</artifactId>
    <version>1.0</version>
    <packaging>war</packaging>
    
    <build>
        <plugins>
            <plugin>
                <groupId>uk.co.codezen</groupId>
                <artifactId>redlinerpm-maven-plugin</artifactId>
                <version>1.0</version>
                
                <configuration>
                    <packages>
                        <package>
                            ...
                            <attach>false</attach>
                            ...
                        </package>
                    </packages>
                </configuration>
            </plugin>
        </plugins>
    </build>
 </project>

Artefact names

By default, all artefact names for RPM packages default to the convention {artefactId}-{version}-{release}.{architecture}.

If you're not happy with this convention, you can override the artefact file name by specifying the XML tag, finalName, as part of the plugin configuration.

Regardless of the artefact name, the artefact can still be attached to the project as a primary or secondary artefact, depending on the configuration documented above.

    ...
    <configuration>
        ...
        <packages>
            <package>
                <finalName>my-project-rpm</finalName>
            </package>
        </packages>
        ...
    </configuration>
    ...
Clone this wiki locally