Is there a maven jigsaw jlink plugin? - java

Does maven have a plugin for the new Java 9 jlink I have searched online but have not been able to find anything official from the maven team.

Yes. There has been some progress made to create one on Github/maven-plugins for the same.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jlink-plugin</artifactId>
<version>3.0.0-SNAPSHOT</version>
</plugin>
The plugin in its code reads to be adaptive to JEP-282 and JEP-220 from the proposals.
And though this might look like a link too many answer. There is a working example from #khmarbaise on Github as well for this, which requires a toolchain with -
<configuration>
<jdkHome>/Library/Java/JavaVirtualMachines/jdk1.9.0_ea+170.jdk/Contents/Home</jdkHome>
</configuration>
Plus a side note from the author quoting -
Currently not more than a Proof of Concept. Everything here is speculative!
Edit1:- As shared in the comments, additional details could be found # How to create a Java runtime with Maven.
Edit2:- Dated 10 November, 2018 one can upgrade to using maven-jlink-plugin:3.0.0-alpha-1 and still provide some valuable feedback.

I'm working on ModiTect, general tooling around Java 9 modules. One of the goals of the ModiTect Maven plug-in lets you create module runtime images via jlink:
<plugin>
<groupId>org.moditect</groupId>
<artifactId>moditect-maven-plugin</artifactId>
<version>1.0.0-SNAPSHOT</version>
<executions>
<execution>
<id>create-runtime-image</id>
<phase>package</phase>
<goals>
<goal>create-runtime-image</goal>
</goals>
<configuration>
<modulePath>
<path>${project.build.directory}/modules</path>
</modulePath>
<modules>
<module>com.example.module1</module>
<module>com.example.module2</module>
</modules>
<launcher>
<name>helloWorld</name>
<module>com.example.module1</module>
</launcher>
<outputDirectory>
${project.build.directory}/jlink-image
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
The plug-in is under active development right now and must be built from source for the time being (will deploy a first version to Maven Central soon).

there is mvn-jlink plugin which allows to call jdeps and jlink (and any tool provided by jdk), also it can download and unpack needed openjdk version from ADOPT and LIBERICA, such way allows build cross-platform images
<plugin>
<groupId>com.igormaznitsa</groupId>
<artifactId>mvn-jlink-wrapper</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<id>call-jlink</id>
<goals>
<goal>jlink</goal>
</goals>
<configuration>
<jdepsReportPath>${project.build.directory}${file.separator}jdeps.out</jdepsReportPath>
<output>${project.build.directory}${file.separator}preparedJDK</output>
<addModules>
<module>java.compiler</module>
</addModules>
<options>
<option>--compress=2</option>
<option>--no-header-files</option>
<option>--no-man-pages</option>
</options>
</configuration>
</execution>
</executions>
</plugin>

Maybe check out https://github.com/ghackenberg/jigsaw-maven-plugin. The plugin also supports
jdeps --generate-module-info + javac + jar for patching unnamed modules,
jlink for creating runtime images, and
jpackage for creating application installers (only available since JDK 14 though).
You find the plugin documentation on the Github README page.
<plugin>
<groupId>io.github.ghackenberg</groupId>
<artifactId>jigsaw-maven-plugin</artifactId>
<version>1.1.3</version>
</plugin>

Related

Versions Maven Plugin rules that are inheritable

When running mvn versions:display-dependency-updates for the Version Maven Plugin I see lots of things like this:
[INFO] org.slf4j:slf4j-api ........................... 1.7.36 -> 2.0.0-alpha7
But just because I'm not using the alpha version of a later version doesn't mean I'm not using the latest available release version. Another Stack Overflow answer indicated that I can set up a rules.xml file to ignore versions like *.-alpha*, putting something like this in my POM:
<configuration>
<rulesUri>file:///${project.basedir}/rules.xml</rulesUri>
</configuration>
My question: is this rules.xml file inheritable? If I put it in a separate project in a parent POM of <packaging>pom</packaging>, published to Maven Central, will the child POMs pick it up? Or will the child projects look for a rules.xml file in the child project directory?
I want to configure the versions-maven-plugin in the parent POM (as I do already) and run mvn versions:display-dependency-updates on any child POM or descendant POM. How can I set up the ignore rules in the parent POM so that these version ignore rules will be picked up when I check for dependency updates in a child POM? (Is there no way to include the rule within the POM itself?)
Or will the child projects look for a rules.xml file in the child project directory?
Yes, if you define the rules.xml file via ${project.basedir} it will resolve to the current local base directory of the child project. I've verified this with a simple parent-child pom setup. So that will not work, unless you duplicate the rules file in every project.
If you wish to include the plugin configuration and ruleset in the parent pom without duplicating the rules file, you have two options:
If you have your ruleset xml file hosted at, for example, http://www.mycompany.com/maven-version-rules.xml then the following configuration in your corporate pom would ensure that all projects use this rule set.
<configuration>
<rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
</configuration>
or
You can provide your ruleset xml file also within a jar, if you want to distribute your ruleset xml as Maven artifact. Therefore you have to declare the containing jar as direct dependency of the versions-maven-plugin and to use classpath as protocol.
<configuration>
<rulesUri>classpath:///package/foo/bar/rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>version-rules</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
Source:
https://www.mojohaus.org/versions-maven-plugin/version-rules.html
The configuration in the pom only has rudimentary includes and excludes filters. Those will allow you to exclude any dependency as a whole, but not specific update versions. As far as i can tell from the available documentation there is no way to define version rules in any other way.
See
https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
Update 09-2022
In the github ticket we found in the comments we can see the following update:
It looks like a feature like this has recently been implemented by #369. Please see #318 where it's possible to provide inclusion and exclusion filters for determining which dependency patterns will be considered. Thanks to that, you can rule out patterns such as .*-beta. or .*_ALPHA, albeit not using regexp, but simple asterisk wildcards.
This will land in today's release (2.12.0).
This will add the following features:
Version 2.12.0 will introduce new arguments: dependencyIncluded, dependencyExcludes, dependencyManagementIncludes, dependencyManagementExcludes.
With the following example configuration in pom.xml given:
<profile>
<id>display-dependency-updates</id>
<build>
<plugins>
<plugin>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<dependencyIncludes>org.apache.maven.*:doxia*</dependencyIncludes>
<dependencyManagementIncludes>com.puppy*:*</dependencyManagementIncludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This will also be implemented for filtering plugin and pluginManagement, but that will probably be added in a later release:
So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.
Pasting my answer here from Github, because I think it might benefit others.
Provided you have a directory called rules-test in your project containing the rules template file:
<ruleset comparisonMethod="maven"
xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0
https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">${ignoredVersions}</ignoreVersion>
</ignoreVersions>
</ruleset>
Then, in your main project, create the following profile:
<profile>
<id>rules-test</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>rules-test</directory>
<filtering>true</filtering>
</resource>
</resources>
<outputDirectory>${project.basedir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.12.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<rulesUri>file://${project.basedir}/compiled-rules.xml</rulesUri>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
If you then execute the following Maven target:
mvn -P rules-test "-DignoredVersions=.*-(M\d*|.*-SNAPSHOT)" clean validate
then you will get a dependencies report using the filter in the -DignoredVersions argument (filtering out both *-M* and *-SNAPSHOT).
And if you put your ignoredVerions property in your project instead of passing it as a -D argument, then it will be inheritable!

How to reference dependencies in license documentation

I'm working on a commercial project which uses many open source libraries as its foundation. It's a Java project and we use maven to resolve dependencies. This is great but ... the companies to whom we want to sell our software are traditionally conservative about what they allow to run on site and will want a full inventory of all third party libraries used. Now I can get the list by looking at our project's pom files to find our first order dependencies and then I suppose use the magic of maven to trace all the transitive dependencies. It will be a long list however and one which is likely to change as we move from version to version of any of the third party packages.
Is there an established approach to documenting this kind of dependency tree?
Is there an accepted "lawyer friendly" form of describing software dependencies that I should be adopting?
Any suggestions would be most welcome!
Cheers
Rich
http://maven.apache.org/plugins/maven-project-info-reports-plugin/license-mojo.html
(a part of http://maven.apache.org/plugins/maven-project-info-reports-plugin/_ )
and
Use license-check-maven-plugin
<build>
<plugins>
<plugin>
<groupId>org.complykit</groupId>
<artifactId>license-check-maven-plugin</artifactId>
<version>0.5.3</version>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>os-check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Reference: https://github.com/mrice/license-check

Two maven versions required in pom.xml - what to do?

I'm trying to build JavaOCR project with mvn clean install. There is used maven-enforcer-plugin in the pom.xml and there are two required Maven versions. (Or maybe I misunderstood something)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<!--different rules for different issues-->
<!--3.3.x causes `java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State` which is caused by certain maven versions, see https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound for details-->
<version>(,3.3)</version>
<!--3.2.x causes `No implementation for org.eclipse.aether.connector.wagon.WagonConfigurator was bound.`-->
<version>(,3.2)</version>
</requireMavenVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
Currently I have installed maven 3.3.3 and it throws the java.lang.NoClassDefFoundError error (same as described in the comment in pom.xml), so I cannot build it.
My question is what version should I use to build the project successfully? Is it possible to use two maven versions simultaneously?
According to Maven's Version Range Specification documentation, that's specifying a range, not a specific version. (,3.2) means anything less than version 3.2, so those two configurations are compatible: for example, use version 3.1.
This is reinforced by the comments in the pom file, which say that versions 3.2.x and 3.3.x cause errors, so don't use them.
See also
Version Range Specification

Can and should a Maven POM specify if it requires Maven 3 or newer?

I am currently doing some cleanup of Java projects which use Maven, and use NetBeans IDE to 'debug' problems in the POM. I have set Maven 3.0.4 in the IDE as the Maven version, but other developers or our Continuous Intgeration system might have different settings.
Is it possible to 'enforce' a specific Maven version directly in the POM (for example by using a Maven 3 specific element)?
Yes you can and you should. Some Maven plugins requires Maven 3 or newer.
Use the maven-enforcer-plugin by adding the following to your pom.xml:
<build>
<plugins>
<plugin>
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.3.1</version>
<executions>
<execution>
<id>enforce-maven-3</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<version>3.0.5</version>
</requireMavenVersion>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Another option is to use the prerequisites element in the pom, for example:
<project>
...
<prerequisites>
<maven>3.0.0</maven>
</prerequisites>
...
</project>
As noted Michal Kalinowski's answer - this simple approach does not work so well for children projects.
For a summary of which approach will work best for you, see here: enforcing maven 3 - when to use maven enforcer plugin? when to use pom prerequisites element?
The best thing you can do is to use Enforcer plugin. Here's an example:
http://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
There is no out-of-the-box method in Maven itself for doing this. There is actually prerequisites tag but it doesn't work well, because children don't inherit it.

How to build an MSI using WIX, JAVA and MAVEN

I'm trying to build an Msi from a java application which is using the spring and maven frameworks. From all the reading up i have done it would seem Wix is the best option. With some further research i started seeing mention of a Wix Maven plugin. The problem is following the websites and what i should place into the pom I don't get the Jar file being found.
has anyone succeded in this or know where to find the jar file?
Below is the Wix maven information.
<plugin>
<groupId>npanday.plugin</groupId>
<artifactId>wix-maven-plugin</artifactId>
<version>${version}</version>
<configuration>
<sourceFiles>
<sourceFile>installer/Kiddo.wxs</sourceFile>
</sourceFiles>
<outputDirectory>target</outputDirectory>
<objectFiles>
<objectFile>target/Kiddo.wixobj</objectFile>
</objectFiles>
<outputFile>target/Kiddo.msi</outputFile>
</configuration>
<executions>
<execution>
<id>wix</id>
<goals>
<goal>candle</goal>
<goal>light</goal>
</goals>
</execution>
</executions>
</plugin>
<dependency>
<groupId>org.apache.npanday.plugins</groupId>
<artifactId>wix-maven-plugin</artifactId>
<version>1.4.0-incubating</version>
</dependency>
these are wrapped with the additional maven tags and
Nathan
Still a work in progress, but you might also be interested in a more fully featured WiX maven lifecycle. There is more than just candle and light.
com.github.wix-maven:wix-maven-plugin
sourced from github

Categories

Resources