I am building three packages with rpm-maven-plugin. One parent, and two plugins that require the parent in the same version. Everything works fine, until I build it with XY-SNAPSHOT version. Then my rpm version gets truncated to XY part, but value of ${project.version} is still XY-SNAPSHOT.
It results in plugins requiring XY-SNAPSHOT version of parent, whereas I have installed XY version.
I wonder if I can use "truncated" version in "requires" section or force a plugin not to truncate my versions...
this is my configuration:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>rpm-maven-plugin</artifactId>
<version>2.0.1</version>
<executions>
<execution>
<id>parent-package</id>
<goals>
<goal>rpm</goal>
</goals>
<configuration>
<name>parent-package</name>
<mappings>
(...)
</mappings>
</configuration>
</execution>
<execution>
<id>first-plugin</id>
<goals>
<goal>rpm</goal>
</goals>
<configuration>
<name>first-plugin</name>
<mappings>
(...)
</mappings>
<requires>
<require>parent-package = ${project.version}</require>
</requires>
</configuration>
</execution>
<execution>
<id>second-plugin</id>
<goals>
<goal>rpm</goal>
</goals>
<configuration>
<name>second-plugin</name>
<mappings>
(...)
</mappings>
<requires>
<require>parent-package = ${project.version}</require>
</requires>
</configuration>
</execution>
</executions>
</plugin>
The RPM specification treats a - as a special character. See this is the best I could find in Google
The version number is used in version comparisons. The RPM comparison algorithm
is fairly complex, but can get fooled by strange version numbers. So, your best
bet is to stick to dotted numerics, such as 1.5 or 2.3.1.1.4 or 1.0. Version
numbers such as these will compare best from within the RPM system. For example:
Version: 1.1.2
You cannot use a dash in the version number, as RPM uses the dash to separate
the Name-Version-Release elements.
So a Maven version such as 1.0-SNAPSHOT would not be a valid RPM version number.
Mojo's RPM Maven Plugin does some transformations on the version number to “help” you. Specifically it strips out the -SNAPSHOT as you have found, and if there was a -SNAPSHOT it sets the rpm release to be SNAPSHOTyyyymmddHHMMSS (note the release is use to differentiate two different builds of the same version of an RPM)
What you need to do is get some properties set to the transformed version. There are a number of ways to do this. As I suggested in a comment you could use build-helper:regex-property to transform the property. The downside of this approach is that if the RPM plugin modifies the rules that it uses for version transformation your regex may leave you out of sync.
The correct solution is to use the rpm:version goal to set the rpm.version property for you, so your configuration becomes:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>rpm-maven-plugin</artifactId>
<version>2.0.1</version>
<executions>
<execution>
<id>properties</id>
<goals>
<goal>version</goal>
</goals>
</execution>
<execution>
<id>parent-package</id>
<goals>
<goal>rpm</goal>
</goals>
<configuration>
<name>parent-package</name>
<mappings>
(...)
</mappings>
</configuration>
</execution>
<execution>
<id>first-plugin</id>
<goals>
<goal>rpm</goal>
</goals>
<configuration>
<name>first-plugin</name>
<mappings>
(...)
</mappings>
<requires>
<require>parent-package = ${rpm.version}</require>
</requires>
</configuration>
</execution>
<execution>
<id>second-plugin</id>
<goals>
<goal>rpm</goal>
</goals>
<configuration>
<name>second-plugin</name>
<mappings>
(...)
</mappings>
<requires>
<require>parent-package = ${rpm.version}</require>
</requires>
</configuration>
</execution>
</executions>
</plugin>
If you need the property to have a different name just use the versionProperty configuration parameter, but keep in mind that with multiple executions you probably want to leave it to its defaults
To expand a bit on #StephenConnolly's excellent answer, the maven and rpm versioning strategies have some specific differences. The differences are mostly around maven's version qualifier and rpm's build (or release) attribute.
Maven treats any version without a qualifier as being newer than a version without a qualifier. Maven also has special handling for any qualifier which ends with SNAPSHOT. RPM on the other hand requires a build number and compares on that value. Not surprisingly, rpm has no special logic for SNAPSHOT.
Since we are working in maven, we need to follow maven's rules/behavior and determine how to massage values in rpm to make that work. What this means is that we need to establish rules for massaging the rpm release value to achieve the following based on maven qualifiers:
1.0-alpha-1-SNAPSHOT
1.0-alpha-1
1.0-alpha-2
1.0-beta-1
1.0-SNAPSHOT
1.0
Additionally, we want multiple SNAPSHOT builds of rpms to be able to identify newer (by build date) and upgrade correctly.
The documentation for the release attribute describe the rules to achieve this desired behavior.
You are welcome to override this default behavior, but I would caution you to be very careful about being sure that rpm being built with identical metadata (arch, os, version, release) contain identical content.
Related
Is there a way to make sure that maven modules are API-compatible to older Java releases without installing and using the specific JDK release? Ie. some plugin?
Example: java.lang.String.isBlank() is available from JDK 11 only, so the plugin should check whether that method has been used if target version is <=10.
Alternatively, I could write a few plugin executions to download/unpack a jdk and then build the current project against that specific jdk. However, that'd be ugly.
the animal sniffer recommendation works great:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>1.17</version>
<executions>
<execution>
<id>verify-java-api</id>
<goals>
<goal>check</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java18</artifactId>
<version>1.0</version>
</signature>
</configuration>
</plugin>
Update: that animal sniffer configuration did not find this issue:
symbol: variable RELEASE_10
location: class javax.lang.model.SourceVersion
I have read up on the limited information regarding com.alexnederlof jasperreports-plugin and I'm looking to convert my current ant build to use this maven plugin, but there doesn't seem to be any documentation available.
My biggest concern is run-time: If I use this plugin at build-time, what version of jasper-reports do I need to use at run-time?
Am I missing a reference somewhere? As the old adage goes, "If there isn't any documentation, then I guess I'll have to write it."
I am not sure of what you are after but, I am using this plugin in maven to generate the source .jrxml files to .jasper files and the configuration in pom goes like this:
<plugin>
<groupId>com.alexnederlof</groupId>
<artifactId>jasperreports-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>jasper</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- These are the default configurations: -->
<compiler>net.sf.jasperreports.engine.design.JRJdtCompiler</compiler>
<sourceDirectory>src/main/jasperreports</sourceDirectory>
<outputDirectory>${basedir}/src/main/webapp</outputDirectory>
<outputFileExt>.jasper</outputFileExt>
<xmlValidation>true</xmlValidation>
<verbose>false</verbose>
<numberOfThreads>4</numberOfThreads>
<failOnMissingSourceDirectory>true</failOnMissingSourceDirectory>
<sourceScanner>
org.codehaus.plexus.compiler.util.scan.StaleSourceScanner
</sourceScanner>
</configuration>
</plugin>
Hope this helps
I'm using maven-release-plugin version 2.4.1, and after executing goal mvn release:prepare -DpreparationGoals="clean deploy -Dmaven.test.skip"
I found that not only version of my application has been changed, but also it adds a space in confuguration in maven-antrun-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>initialize</phase>
<configuration>
<tasks>
<delete includeEmptyDirs="true" dir="com.project.HelloWorld"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
Space added right between "com.project.HelloWorld" and slash. Issue lies in that fact, that xml-format-plugin remove this space after Maven build, but after each release I see this annoying space again.
Does anybody know why this happened or how to overcome this issue?
According to Extensible Markup Language (XML) 1.0 (Fifth Edition) – 3.1 Start-Tags, End-Tags, and Empty-Element Tags a white space character is absolutely OK:
Tags for Empty Elements
[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [WFC: Unique Att Spec]
Annoying or not is a matter of POV, IMHO. I personally prefer them.
I have several levels of nested Maven projects, where every module can participate in the global integration tests. To have a global, multi module coverage, I've configured jacoco to use and share the same file accross modules, using the Maven variable ${session.executionRootDirectory}:
<execution>
<id>pre-integration-test</id>
<phase>pre-integration-test</phase>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<propertyName>jacoco.failsafeArgLine</propertyName>
<destFile>${session.executionRootDirectory}/target/jacoco-it.exec</destFile>
</configuration>
</execution>
This way, the same data file is used by each module, no matter how deep it is nested in the submodules. I've checked, a correct data file is generated by jacoco when launching "mvn clean install".
Now the problem appears when launching mvn sonar:sonar. It seems that the plugin can not replace that variable with the real path. I can see the following in the logs
[INFO] JaCoCoItSensor: JaCoCo IT report not found: /home/tomcat/.jenkins/jobs/MYJOB/workspace/${session.executionRootDirectory}/target/jacoco-it.exec
It doesn't work better when using #{session.executionRootDirectory}.
Any workaround?
Following a comment in this bug report at SonarSource, advising to use the following configuration:
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>set-sonar.jacoco.reportPath</id>
<goals>
<goal>set-properties</goal>
</goals>
<phase>initialize</phase>
<configuration>
<rawProperties>
sonar.jacoco.itReportPath = ${session.executionRootDirectory}/target/jacoco-it.exec
</rawProperties>
<addDollar>true</addDollar>
</configuration>
</execution>
</executions>
</plugin>
... which was unfortunately not compatible with Maven 3.1+, I've used and built from sources that fork, and then I was able to make everything work correctly with Maven 3.2.3.
I'd like to rename all dependencies to strip off SNAPSHOT so my file handling scripts and installer don't break when I release.
I presently, use maven-dependency-plugin:copy-dependencies and copy with individual artifacts listed and renamed. I'd rather have something akin to ant's regex mapper establish a renaming rule.
Presently, I plan to copy-dependencies to 1st stage directory in prepare-package and use antrun's copy + regex mapper in package to copy/rename but that wastes time and space.
Is there a more direct way to approach this problem? Can the dependency plugin handle rule based renames?
Thanks
Peter
If you just want to remove the version from the dependencies, then add the stripVersion parameter to the plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy-dependencies</id>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<silent>true</silent>
<outputDirectory>libs</outputDirectory>
<stripVersion>true</stripVersion>
<includeTypes>swc</includeTypes>
<excludeGroupIds>com.adobe.flex.framework</excludeGroupIds>
<excludeTypes>pom</excludeTypes>
</configuration>
</execution>
</executions>
</plugin>