Develop Reference

Is there a maven jigsaw jlink plugin?

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>

Can maven change package declarations when compiling a project?

Well, I have googled this topic many times and I haven't found an answer yet: Can maven change the package declarations right before compiling a project?
My objective is have project A, which is an API, all in one package, and each project B and C will use the same dependency on eclipse. My objective is that once maven is about to compile the project, the package declarations get changed to that project's specific package and then it compiles the project.
This is useful because I have many projects using the same API and I keep making changes to the API itself to suit my needs, but it's a pain to have to go trough every project and change it all again.
If you have any idea how to do this, and, more importantly, if it is possible, let me know please. Thanks in advance!

Google's maven replacer plugin can do such things, it can edit your java files at build time. I have used it for silencing warnings in automatically generated java files. It can definitely be used for even more evil things.
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>maven-replacer-plugin</artifactId>
<version>1.3.2</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>
<include>src/main/java/mycodegen/**/*.java</include>
</includes>
<regex>true</regex>
<regexFlags>
<regexFlag>MULTILINE</regexFlag>
</regexFlags>
<replacements>
<replacement>
<token>^public class</token>
<value>#SuppressWarnings("all") public class</value>
</replacement>
</replacements>
</configuration>
</plugin>
This is what I had used. It should be very similar to change package declarations in Java files. By now there should be much newer versions of the plugin.

Maven, Lombok and Eclipse - Meaningful Integration Pattern

So, I've been wanting to use Lombok for a while - and I'm finally starting a project where I will be able to use it. The important thing to note is that this will be a large, enterprise-grade application and thus the integration patterns used have to be meaningful, with as few hacks as possible.
So I've taken a look at the lombok-maven-plugin, and the whole delombok fudge. I understand this is going to duplicate all my code, and expand the lombok annotations where present. This gives me a second set of generated .java files that need to be used by maven during compilation.
However, by generating these new source files - eclipse picks them up and attempts to pull them into my project. Thus it fires off a million (OK, slight exaggeration) errors about duplicate classes.
Some solution suggest I change the <sourceDirectory> in my POM. This makes things no better, as a mvn eclipse:eclipse will now completely omit my src/main/java java directory from the project - only showing me the output from the delombok process.
Then come the suggestions that I need to use one profile to compile / package the project, and another to mvn eclipse:eclipse. This is not an acceptable solution, as I’m having to spend enough time maintaining / explaining my already complex maven setup – without having to introduce an entire new profile (in addition to my existing profiles).
I’m hoping for some inspiration to save me from writing off Lombok for my project. It’s a great tool to reduce boilerplate code, but it simply doesn’t seem ready for prime-time enterprise usage – which I find very disappointing :-(
The following is my current POM:
<build>
<sourceDirectory>target/generated-sources/delombok</sourceDirectory>
<testSourceDirectory>target/generated-test-sources/delombok</testSourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.projectlombok</groupId>
<artifactId>lombok-maven-plugin</artifactId>
<version>1.12.2.0</version>
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
<version>1.7</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
<executions>
<execution>
<id>delombok</id>
<phase>generate-sources</phase>
<goals>
<goal>delombok</goal>
</goals>
<configuration>
<encoding>UTF-8</encoding>
<addOutputDirectory>false</addOutputDirectory>
<sourceDirectory>src/main/java</sourceDirectory>
</configuration>
</execution>
<execution>
<id>test-delombok</id>
<phase>generate-test-sources</phase>
<goals>
<goal>testDelombok</goal>
</goals>
<configuration>
<encoding>UTF-8</encoding>
<addOutputDirectory>false</addOutputDirectory>
<sourceDirectory>src/test/java</sourceDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Which is currently only putting the delomboked code in my eclipse project.
Final note - I'm also quite frustrated that I have to manually install lombok on all the eclipse instasnces we're going to use. Mostly because it's me who will get the phonecall from all the developers that can't get it working. I get why it's not as simple as mvn eclipse:eclipse but I still wanted to note my dissapointment. If we had to manually set up every library for use on each developer's machine, we'd be back in the pre-maven days.

We are successfully using lombok in our project for 1.5 years now. We're not using any delombokification, but instead have lombok as a provided dependency like so
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>0.11.0</version>
<scope>provided</scope>
</dependency>
That's all it needs. We can use the lombok annotations and they are recognized by both eclipse and maven builds. This is even compatible with EclEmma in eclipse, which marks the annotations as (un)covered, when the respective generated code is(n't).
You have to install it on every Eclipse instance manually, since most of the JDT isn't open for eclipse plugins to modify. That's a technical restriction the lombok developers cannot lift. Anyways, the installer is quite simple and never failed me so far.

You don't necessarily need to use lombok-maven-plugin to take advantage of Lombok. As I understand, the delombofication that the plugin does is meant to allow things like code coverage and javadoc to have a full version of the code. Even then, the process would only occur at, say, Javadoc building time.
The question is if your project can live without that. If yes, then just adding lombok as Maven dependency is all you need.
In Eclipse you'll indeed need to install it. Note that the fact the Lombok is still kind of experimental, is perhaps of the reasons it's not included in Eclipse by default.

How to check project boundaries access in Maven projects

I have a set of Maven projects and I'd like to define access rules.
For example, projects Database and Cache may only be accessed by project DataLayer, but not from project UiLayer. I'm speaking in terms of maven projects, but a package level access verification may also work, as long as it's easy to integrate into maven projects.
I've looked at Macker, which has a nice set of features such as access control b/w java packages, style checking etc, but have been having hard time tying that into a set of maven projects.
There's the macker-maven-plugin, which is still under development, and I've been able to make it work for me, but I'm afraid it's not going to serve me well.
This plugin runs verifications on all project's classes.
This means that I'll have to have macker-rules.xml defining access rules in each and every maven project from now on in order to make sure rules are not broken. This looks like a maintenance nightmare.
So - did I miss something with usage of macker-maven-plugin? Perhaps I'm not using it correctly.
I have no experience with JDepend, but from short reading it looks like the thin version of macker. There is a jDepend maven plugin, but it's functionality is merely generating reports about usage and statistics, but what I really need is something else, an access check which fails the build if it fails.
Can someone suggest a better alternative for project access checks or package access checks for maven projects?
Thanks

I think you are looking for banned dependencies from maven-enforcer-plugin.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>enforce-banned-dependencies</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.apache.maven</exclude>
<exclude>org.apache.maven:badArtifact</exclude>
<exclude>*:badArtifact</exclude>
</excludes>
<includes>
<!--only 1.0 of badArtifact is allowed-->
<include>org.apache.maven:badArtifact:1.0</include>
</includes>
</bannedDependencies>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>

If you split your Maven project into subprojects and structure the APIs right, it might be possible to implement your access constraints as a side-effect of the subproject dependencies.

In Maven2, is there a way to scope a dependency to "package only" and keep it off the test classpath?

Setup
I'm packaging a WAR with a number of legacy jar dependencies in it (for the sake of keeping this simple, they can not possibly be altered or excluded from the deployed WAR).
Issue
Including either or both of two of these jars will cause inexorable errors at test-time. If I exclude the dependencies altogether, the tests pass happily, but the WAR will lack real-world runtime classes it needs.
Hope
Maven2 offers compile, test, runtime, system, and provided scopes. Sadly, none of these will be included in the assembly but kept off the test classpath. My hope is that I'm missing some obvious way to handle this case entirely within the dependency management feature.
Fear
I'll have to use the assembly plugin to copy these problem jars into the target. I don't want to have to skirt the dependency management system to copy jars in the clear into the target, as I don't want to manage these jars outside the internal repository.
Thoughts? Alternatives?

Of course it figures that I'd come across a potential solution to this moments after posting a question. It appears that the copy goal of the dependency plugin may handle this. Going to try this out now: http://maven.apache.org/plugins/maven-dependency-plugin/usage.html
Edit: Turns out that this worked fine for my needs, snippet below:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>copy</goal>
</goals>
</execution>
</executions>
<configuration>
<artifactItems>
<artifactItem>
<groupId>group</groupId>
<artifactId>artifact</artifactId>
<version>version</version>
<type>jar</type>
<outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/lib</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</plugin>

Break the test classes out of the jar file into a separate jar which is only for tests, and add an exclusion to the dependency on the jar with the legacy dependencies.