We Keep Coding

Problem running tests with enabled preview features in surefire and failsafe

I'm trying to migrate a project to Java 12, with --enable-preview.
I added --enable-preview in compiler settings:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>12</release>
<compilerArgs>
<arg>--enable-preview</arg>
</compilerArgs>
</configuration>
</plugin>
And also added it in argLine for surefire and failsafe:
<properties>
<argLine>--enable-preview</argLine>
</properties>
And do a mvn clean verify results in:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) on project lombok-jdk10: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed: java.lang.UnsupportedClassVersionError: Preview features are not enabled for com/kirela/lombok/BarTest (class file version 56.65535). Try running with '--enable-preview' -> [Help 1]
I also tried adding argLine directly to surefire/failsafe configuration, but the result is same.
What am I missing here?
I this a bug in surefire/failsafe?
EDIT2: Surefire and failsafe config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<forkCount>2</forkCount>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M3</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<forkCount>2</forkCount>
</configuration>
</plugin>
EDIT3:
Minimal working example is here: https://github.com/krzyk/lombok-jdk10-example
The project fails with --enable-preview, but works when I remove it.

This works for me:
mvn clean install works (with junit tests)
IDEA recognizes module language level correctly as 12 (Preview) - Switch expressions
junit tests in IDEA work
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>12</release>
<compilerArgs>
<arg>--enable-preview</arg>
</compilerArgs>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<argLine>--enable-preview</argLine>
</configuration>
</plugin>
Environment:
Ubuntu 18.04.3 x64
IDEA 2019.2.1
Maven 3.6.0
jdk:
IMPLEMENTOR="Oracle Corporation"
JAVA_VERSION="12"
JAVA_VERSION_DATE="2019-03-19"
ADDITION: Similarly this approach works for java 13.
ADDITION: Similarly this approach works for java 17.

There are two solutions:
Add --enable-preview to MAVEN_OPTS environment variable.
Explanation by the maintainer of surefire:
The argLine does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked JVM.
Due to the classes are compiled with different major or minor version (in bytecode of *.class files) than the version of Java runtime supports in Maven, this JRE fails because Java in Maven does not understand the bytecode. So, it is curious that the same JVM (javac) produced two major versions depending on JVM option and java from the same JVM does not understand it been incompatible for itself. Although version in forked JVM is totally fine and understands the the classes compiled by javac because javac and forked JVM start with the same option --enable-preview.
It is the same situation as if you compiled your sources with Java 12 by maven-compiler-plugin using the toolchain and run the whole Maven build with Java 11. So the classes would be compiled with higher version (in bytecode) than the JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the forked JVM but this is very compilicated change and still questionary.
The issue is that I used forkCount, it appears surefire doesn't pass parameters to JVM run in fork.
Remove the forkCount parameter from surefire/failsafe configuration.
This will of course cause the tests to run in a single JVM, so if you wanted to speed up the tests using the forks, it won't work now.

Add a configuration for surefire and failsafe maven plugin
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>--enable-preview</argLine>
</configuration>
</plugin>
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<argLine>--enable-preview</argLine>
</configuration>
</plugin>

Automatically generate Java from .proto with maven/m2e in Eclipse IDE

For my team, I'd like to configure maven/eclipse build to automatically generate Java code from *.proto files (in a project that uses gRPC). Currently one needs to run mvn generate-source or mvn protobuf:compile (as in plugin usage page). Or what is the same add Run configuration to invoke maven goal compile.
Whenever Eclipse Maven project is refreshed (Alt+F5) or IDE is restarted, project is rebuilt but without what should appear in target/generated, thus turning project into red. So one need to generate and refresh project (F5). UPDATE Eclipse has needed source folders configured in .clathpath file.
As I know that should be m2e connector, but I could only find one https://github.com/masterzen/m2e-protoc-connector for the oldest Googles plugin com.google.protobuf.tools:maven-protoc-plugin, that is even not mentioned currently at https://github.com/grpc/grpc-java
We use exactly referenced/recommended
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
that is:
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.4.1.Final</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.5.0</version>
<configuration>
<protocArtifact>com.google.protobuf:protoc:3.1.0:exe:${os.detected.classifier}</protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.0.1:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Related:
Linking to generated Java protobuf code in Eclipse
looked at this but that author was using other older, not supported now plugin : Eclipse build loop caused by protobuf generated code (related to Maven Project Builder)
P.P.S That plugin https://github.com/igor-petruk/protobuf-maven-plugin however has continuation as https://github.com/os72/protoc-jar-maven-plugin

Instead of using org.xolstice.maven.plugins:protobuf-maven-plugin my team has used com.github.os72:protoc-jar-maven-plugin to generate the message classes. I believe they are the same since under the hood they all seem to be using the tools from Google.
I am not using any m2e connectors for this plugin (Edit: protoc-jar-maven-plugin's m2e connector is bundled with it so no extra installation is needed, which is why it seemed like I wasn't using one, but technically I was, but this doesn't really matter). Unfortunately the changes in the .proto file are not "automatically" propagated to the generated .java files, you need to manually run Maven or trigger the project to be built in Eclipse (instructions below), but fortunately the target/generated-sources file is not vanishing or emptying or anything strange like what you describe.
If you want to rebuild the .java files from the .proto classes without using mvn clean compile from the command line you can clean the Eclipse project . Project → Clean... → select your project → Select build option (only shows if you have "Build Automatically" from the Project menu is unchecked).
I was able to do this in the latest Eclipse Neon (it will probably work in later ones too, but I don't know for certain).
Below is the POM I am using. I don't think it requires any special explanation, my solution is to simply use a different plugin than the one you are using. (If some explanation is needed I'll be happy to provide it though.)
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>io.github.jacksonbailey</groupId>
<artifactId>protobuf-m2e-sample</artifactId>
<version>0.1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.github.os72</groupId>
<artifactId>protoc-jar-maven-plugin</artifactId>
<version>3.1.0.1</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<protocVersion>3.1.0</protocVersion>
<inputDirectories>
<include>src/main/resources</include>
</inputDirectories>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

for protobuf-maven-plugin
Thanks to sergei-ivanov answer in https://github.com/xolstice/protobuf-maven-plugin/issues/16, that gave link https://github.com/trustin/os-maven-plugin#issues-with-eclipse-m2e-or-other-ides :
One need to download os-maven-plugin-x.x.x.Final.jar (the version as in your pomx.ml) and put it into the <ECLIPSE_HOME>/plugins directory.
After that Eclipse will generate source on project clean, including after Maven -update project... (Alt+F5), but not after Project -> Build (or with default Build Automatically). Also on IDE start it will not compile.
Yes, that is illogical:
Project - Clean will generate and compile Java source
but
Project - Build will not.
P.S. Raised Bug 507412

Both eclipse and vscode can automatically compile proto when changed.
<plugin>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.6.2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>detect</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.6.1</version>
<configuration>
<protocArtifact>com.google.protobuf:protoc:3.12.0:exe:${os.detected.classifier}</protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.32.1:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>8</source>
<target>8</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
See: https://github.com/trustin/os-maven-plugin#issues-with-eclipse-m2e-or-other-ides

maven jaxws-maven-plugin not adding generated packaged build path

I use mvn compile and I have a pom that uses jaxws-maven-plugin to create client classes, which it does fine. I get all my classes inside target>generated-sources>wsimport> path. But the classes aren't being added to my classpath. So my project does not compile.
plugin in pom.xml
<build>
<plugins>
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlDirectory>${basedir}/src/main/resources/wsdl</wsdlDirectory>
<packageName>org.tempuri</packageName>
<vmArgs>
<vmArg>-Djavax.xml.accessExternalSchema=all</vmArg>
</vmArgs>
<!-- needs extension true otherwise wont generate trade web service stub. Still shows error SOAP binding 1.2 -->
<extension>true</extension>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

The issue was the version of the plugin jaxws-maven-plugin. For some reason I was using version 2.3.1-b20150201.1248. When I changed to2.3 it worked fine.
The old version generated the proxy classes just fine but it did not add to classpath in Eclipse. There were no errors, But when I opened the project in Netbeans when I tried to generated the proxy classes from WSDL I got the error
No implementation for org.eclipse.aether.impl.ArtifactDescriptorReader
was bound.
So I changed version of the plugin like this answer said:
https://stackoverflow.com/a/25277703/1754020
and it worked fine.

Relationship between Eclipse default JRE, project compliance and compiler used

I couldn't understand for some time why my Maven project wasn't building in Eclipse and presented me with "Bad version number in .class file" errors.
I checked all my dependencies and ensured they were built for Java 6 or lower (using this handy JAR version checking tool).
I opened my project properties and confirmed I had project-specific compiler settings, set to compliance level 1.6.
I also confirmed I had the Java 6 libraries on my build path.
Finally, I discovered the cause was related to the default JRE selected for my workspace. This was set to jdk1.5 for some reason. Setting this to something higher than this (I chose jdk1.8) solved the issue. In the end, I had to select jdk1.7 to allow my AspectJ weaving to work correctly.
My question is: why did this solve it? According to the preferences page, this setting only influences which JRE is added to the build path of newly created Java projects. I can't fathom why this would affect my ability to build my project. Any suggestions? It seems as though Eclipse uses the default JRE selection to influence what type of compiler is used.
I'm using m2e to bind Eclipse and Maven. My POM build section is as follows:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<!-- http://maven.apache.org/plugins/maven-compiler-plugin/ -->
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.5</version>
<configuration>
<complianceLevel>1.6</complianceLevel>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Maven Javadoc aggregate-jar plugin fails because of unresolved dependencies

I have multi-module Maven project in which I run the maven-javadoc-plugin to generate javadoc. In my parent pom.xml I have defined the plugin build as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<!-- Default configuration for all reports -->
</configuration>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate-jar</goal>
</goals>
<phase>install</phase>
<configuration>
<!-- Specific configuration for the aggregate report -->
</configuration>
</execution>
</executions>
</plugin>
When I run mvn clean install the build fails with unresolved dependencies, but I see the following warning:
[WARNING] The dependency:
[my.application:my-module:jar:1.7.1] can't be resolved but
has been found in the reactor (probably snapshots). This dependency
has been excluded from the Javadoc classpath. You should rerun javadoc
after executing mvn install.
As I am currently building my-module 1.7.1, I would assume Maven to detect this and run the aggregate-jar after building my-module, but for some reason it expects my-module to already be installed in a repo.
My Maven version is 3.0.4. Please keep in mind that I am new to Maven builds so this may be a very simple question, but I was not able to find any answer.
Some observations:
The build succeeds if I first run mvn clean install without the javadoc plugin aggregate-jar goal
The javadoc plugin aggregate goal runs fine.
This bug refers exactly to my issue, but should have been solved in Maven 3 (2010)

I run this command in my parent pom and this is how I do it without issues:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
When I want to generate the docs, I do mvn javadoc:aggregate