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
Related
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 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 am currently trying to sign my packaged jars etc. with the maven GPG Plugin (http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html).
I found on several sites (for example here: https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven ) the hint, that one could do this with the following code in once pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Unfortunately, if I do this, and run maven package gpg:sign, it stops when trying to sign. If I add <version>1.4</version> (like in Maven GPG plugin not signing sources and javadoc jars), it works fine. Normally, it uses version 1.5, and if I specify that it should use this version, it does not work. Does anyone know what the reason of this behavoir is, and how I need to configure the maven-gpg plugin to run correctly with version 1.5?
I try to download Oracle (Sun) Java JDK via maven without success:
<dependency>
<groupId>com.sun</groupId>
<artifactId>jdk</artifactId>
<version>6u45</version>
<classifier>dlj-linux-i586</classifier>
<type>bin</type>
</dependency>
What maven repository should I use to download Oracle (Sun) Java JDK?
Added
I want to find a way to download DLJ version of jdk-6u45-linux-i586.bin JDK installer by maven, without manually download.
Now i have standard maven error when dependency is not configured well or a maven repository is missed:
Missing:
----------
com.sun:jdk:bin:dlj-linux-amd64:6u45
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun -DartifactId=jdk -Dversion=6u45 -Dclassifier=dlj-linux-amd64 -Dpackaging=bin -Dfile=/path/to/file
How to download JDK installer by maven?
You can't. The JDK installer is not in any public Maven repository. If it was, the Oracle lawyers would be sending "cease and desist" letters.
I am aware that you could use the Maven exec plugin (or similar) to "work around" Oracle's click through license agreement. However, this is arguably illegal under US law. Consider what happened to "weev" when prosecutors decided to make an example of him.
When you're running on a linux machine, you can download the jdk using maven-exec-plugin calling curl/wget :
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<!-- using curl -->
<execution>
<id>download oracle jdk (curl)</id>
<phase>process-resources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>curl</executable>
<arguments>
<argument>-L</argument>
<argument>--header</argument>
<argument>Cookie: s_nr=1359635827494; s_cc=true; gpw_e24=blub; s_sq=[[]]; gpv_p24=novalue</argument>
<argument>http://download.oracle.com/otn-pub/java/jdk/6u45-b06/jdk-6u45-linux-i586.bin</argument>
<argumen>-o</argumen>
<argument>${project.build.directory}/curl-jdk-6u45-linux-i586.bin</argument>
</arguments>
</configuration>
</execution>
<execution>
<!-- using wget -->
<id>download oracle jdk (wget)</id>
<phase>process-resources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>wget</executable>
<arguments>
<argument>--no-cookies</argument>
<argument>--header</argument>
<argument>Cookie: s_nr=1359635827494; s_cc=true; gpw_e24=blub; s_sq=[[]]; gpv_p24=no value</argument>
<argument>http://download.oracle.com/otn-pub/java/jdk/6u45-b06/jdk-6u45-linux-x64.bin</argument>
<argument>-O</argument>
<argument>${project.build.directory}/wget-jdk-6u45-linux-x64.bin</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
...
I have developed maven plugin which can download and unpack OpenJDK from different providers (Liberica, Adopt, SapMachine), it is useful for preparing cross-platform JDK images in distributives
<plugin>
<groupId>com.igormaznitsa</groupId>
<artifactId>mvn-jlink-wrapper</artifactId>
<version>1.0.2</version>
<executions>
<execution>
<id>cache-jdk-8</id>
<goals>
<goal>cache-jdk</goal>
</goals>
<configuration>
<jdkPathProperty>jlink.jdk.path</jdkPathProperty>
<jdkCachePath>${project.build.directory}${file.separator}jdkCache</jdkCachePath>
<provider>ADOPT</provider>
<providerConfig>
<release>jdk8u192-b12</release>
<arch>x64</arch>
<type>jdk</type>
<impl>hotspot</impl>
</providerConfig>
</configuration>
</execution>
</executions>
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.