We Keep Coding

Vaadin: Can't build on production mode

I try to put my app in production mode, I'm on vaadin flow 14.1.5, the profile is already on the pom.xml.
production profile on the pom.xml is like this:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<jvmArguments>-Dvaadin.productionMode</jvmArguments>
</configuration>
</plugin>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
However when running on the terminal: mvn clean package -P production
I got this:
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.437 s
[INFO] Finished at: 2020-04-25T00:22:09-04:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.vaadin:vaadin-maven-plugin:14.1.5:build-frontend (default) on project project-maya: Execution default of goal com.vaadin:vaadin-maven-plugin:14.1.5:build-frontend failed: Unsupported class file major version 58 -> [Help 1]
I'm on testing at the moment so I don't really care about running on development mode but I will be running on production mode soon and I really don't know what to do to fix this.

Edit: Vaadin 14.1.26 has now been released, which includes the fix for not being able to build with Java 14 (Flow issue #7918).
This is most likely an issue with Java 14.
There's a fix in Flow version 2.1.9 and 2.2.0.beta2.
Vaadin 14.1.25 still uses 2.1.8, hopefully there will be a new version with 2.1.9 soon.
Vaadin 14.2.0.beta1 uses 2.2.0.beta2, so if you want you could try that.
Hopefully the fix is available in a stable release once you need production mode to work.

properties-maven-plugin does not set System propertey correctly

I am trying to set a system property in my java project with the maven plugin properties-maven-plugin. Here is my maven code:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<goals>
<goal>set-system-properties</goal>
</goals>
</execution>
<configuration>
<properties>
<property>
<name>system.property.name</name>
<value>${myvalue}</value>
</property>
</properties>
</configuration>
</executions>
</plugin>
...
I can see that is executed in the maven run:
[INFO] --- properties-maven-plugin:1.0.0:set-system-properties (default) # myproject ---
[INFO] Set 1 system property
[INFO]
But in then it is not present at runtime. For example I can not get it with System.getProperty("system.property.name")
I do not understand why. Funny thing is: It worked at one time and then it didn't, without me changing anything.
I also get this strange Eclipse error at the execution-tag: "Plugin execution not covered by lifecycle configuration: ..." but I think this is an Eclipse problem?

The system property is set for the build. After the build is over, it is gone. If you start the built program later, it does not have that system property.

Maven JAR Plugin 3.0.2 Error: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them

Maven JAR plugin (version 3.0.2) keeps throwing the following error, even for a single invocation of the jar goal:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.2:jar (default) on project test: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1]
Here's a (minimal?) pom.xml which demonstrates the problem:
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>1.0.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
The invocation is just mvn package.
It doesn't seem to matter whether there are any classes/resources at all — the above error message appears anyway.
The problem also appears if two goals are specified (jar and test-jar).
The problem does NOT appear if no goals are specified. But this is not an option, since I really need both jar and test-jar.
According to the documentation, classifier only needs to be specified on multiple invocations of the same goal, and there's a reasonable default for the test-jar goal which I don't intend to change.
Also, the problem doesn't seem to appear on the 2.x line of the JAR plugin.
Did I miss something?
Could anybody please suggest what I am doing wrong?
P.S. The Maven version is 3.3.9.

The Jar Plugin is actually getting executed twice with the configuration:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
If you check the logs with such a configuration, you will have something like:
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) # test ---
[INFO] Building jar: ...\test\target\test-0.0.1-SNAPSHOT.jar
[INFO]
[INFO] --- maven-jar-plugin:3.0.2:jar (default) # test ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
meaning that the plugin was in fact executed twice. What happens, is that the Jar Plugin, in a project that has a packaging of jar has a default execution bound to the package phase. This default execution is the one mentioned in the logs with the ID of default-jar.
When you configured an <execution> in the plugin, you actually configured a new execution, where the jar goal of the plugin is to be invoked. Since the jar goal binds by default to the package phase, that execution is getting executed at that phase, after the default binding inherent to the jar packaging. And since the plugin ran already, it is failing because running it again would actually replace the main artifact already produced during the first run. This error was added in version 3.0.0 of the plugin in MJAR-198, because such a thing happening is very likely a mis-configuration which should be detected early.
As such, the fix is simple: don't have an execution that specifies the goal jar, and let the default one (coming from the jar packaging) do the work. The JAR will still be created, even without the explicit configuration of the jar goal, thanks to the default execution. If you want a test JAR as well, you will still need to configure the plugin to do that with:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
But note that the goal jar is not specified.

In my case, I have set the execution ID to default-jar, overriding the default execution. Then the error is gone.
<execution>
<id>default-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>

If your logs shows something like:
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) # test --
[WARNING] JAR will be empty - no content was marked for inclusion!
Adding a single useless class in src/main/java seems to solve the issue see:
http://maven.40175.n5.nabble.com/quot-mvn-clean-verify-deploy-quot-causes-jar-plugin-to-execute-twice-td5877166.html
Since the above link might be broken as of 2021-09 you might want to try http://mail-archives.apache.org/mod_mbox/maven-users/201608.mbox/thread as an alternative

One reason to have this error may be that the package goal is mistakenly executed twice:
mvn ... package ... package
May happen when the command is built by imperfect scripts :)

A little late but you should add <phase>none</phase> to default-jar execution. this will skip it.
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
This will skip the default-jar but others are executed. Make sure you put <phase>package</phase> in the rest of the execution threads.

maven-release-plugin and Arquillian

I have such project structure:
Parent
ProjectA
ProjectB
ProjectA produces an ear. The Arquillian based test of ProjectB depends on ear of the ProjectA (create additional deployment with ProjectA ear). Maven install goal works fine but release:prepare and release:perform are - not. The maven-release-plugin on a one of the first phases increases the version of the project. And when ProjectB constructs a deployment of ProjectA it can't find an artifact with a new version (but it exists in workspace - not in local repo):
java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.EnterpriseArchive com.....SchemaCreationTest.createFleetEmulator()
[INFO] at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:434)
[INFO] at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
[INFO] at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:367)
[INFO] at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.resolveDependencies(MavenRepositorySystem.java:121)
[INFO] at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:228)
[INFO] at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
[INFO] at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withoutTransitivity(MavenStrategyStageBaseImpl.java:58)
[INFO] at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withoutTransitivity(MavenStrategyStageBaseImpl.java:40)
I resolve artifacts with such command:
Maven.configureResolver().offline().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies().resolve().withoutTransitivity().asResolvedArtifact();
P.S. mvn release:prepare works fine if I set on the dryRun option.
How can I resolve artifacts when maven release:prepare works?

Depending on how your test cases are structured, having the Arquillian tests as integration tests allow them to be executed separately.
If required, integrate the maven-failsafe-plugin:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<parallel>methods</parallel>
<threadCount>1</threadCount>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>2.19.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
<plugins>...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
Rename your test class so that its detected as an integration test. I.e. rename AcmeTest to AcmeIT, then your arquillian tests will be executed as integration tests, i.e. use mvn verify to run the arquillian tests.
This in itself doesn't resolve the problem. As a simple work around, if this is the only integration tests being executed, you can add -Darguments="-DskipITs" to your mvn release:prepare and your arquillian tests will be skipped. You can also add JUnit categories to the arquillian tests and filter at that level. More info is available on the maven-failsafe-plugin site.

How does Maven and/or Junit control how many times tests are run?

I'm hoping someone can enlighten me on how junit, maven-surefire-plugin or maven controls how many times to run a test, or if there's something in config or property files somewhere that I failed to find/lookup/set that controls the number of times.
For some reason, when I run my tests in maven, they get executed twice. I see it in the console output. I think the maven-surefire-plugin might be part of the reason but I'm not sure.
I run the command:
mvn -Dtest=TestClassBlah test
I see the log msgs in the console that it starts up, runs the tests, gives a summary, then runs it again for whatever reason:
(Log file sanitized and abridged. Pls excuse any typos from the sanitizing)
[INFO] Scanning for projects...
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building TestClassBlah 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
<snip snip>
<snip snip>
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.blah.blah.TestClassBlah
<bunch of INFO and other msgs>
<bunch of INFO and other msgs>
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.465 sec
Results :
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] --- maven-surefire-plugin:2.11:test (tests) # TestClassBlah ---
[INFO] Surefire report directory: /dir/somewhere/for/me
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.blah.blah.TestClassBlah
<bunch of INFO and other msgs again>
<bunch of INFO and other msgs again>
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.767 sec
Results :
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.799 s
[INFO] Finished at: 2014-08-07T18:54:27+01:00
[INFO] Final Memory: 19M/183M
[INFO] ------------------------------------------------------------------------
I can attach my pom.xml file if needed, although, it just lists our plugins, dependencies, repos, etc. It doesn't seem to list number of times to run tests or suppress output from surefire-plugin.
We use the maven-surefire-plugin to post our results in Jenkins. This is my first time using these technologies so I don't know all the tricks of the trade yet. Thanks in advance for any help you can give me.
UPDATE: Here's the pom. Sorry it's kinda long.
<modelVersion>4.0.0</modelVersion>
<groupId>GenericGroupName</groupId>
<artifactId>TestClassBlah</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>TestClassBlah</name>
<dependencies>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>com.genericname</groupId>
<artifactId>analytics</artifactId>
<version>1.5-RELEASE</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
<dependency>
<groupId>org.skyscreamer</groupId>
<artifactId>jsonassert</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit-dep</artifactId>
<version>4.11</version>
<exclusions>
<exclusion>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<executions>
<execution>
<id>tests</id>
<goals>
<goal>test</goal>
</goals>
<configuration>
<excludes>
<exclude>none</exclude>
</excludes>
<includes>
<include>**/*.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>bitExpert-nexus-releases</id>
<name>bitExpert nexus</name>
<url>http://10.196.32.21:8081/nexus/content/groups/public/</url>
</repository>
</repositories>

You have an extra execution of maven-surefire-plugin specified in your pom. Maven has a default execution of Surefire that's running as well. If there's a tag under the of Surefire in your pom, you can move that up under the tag for maven-surefire-plugin and it will be applied to the default execution of maven-surefire-plugin. Then you can delete the extra execution.
If you want Surefire to run one way on desktops and another way in Jenkins, that's a good use case for profiles.
Edit: after looking at your pom this should definitely work and only run surefire once:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<configuration>
<excludes>
<exclude>none</exclude>
</excludes>
<includes>
<include>**/*.java</include>
</includes>
</configuration>
</plugin>
You might be able to remove the entire <configuration> tag depending on how test classes are named--Maven normally interprets every class under src/test/java whose name starts with Test or ends with Test or TestCase as a test class. If all your test classes already follow that convention, then configuring Maven to hoover up every class as a test class is just redundant.

The simplest answer to this is that the surefire plugin is specified in your pom (and/or its parents) with more than one execution, or there are two plugins that perform the same action (I haven't seen it with surefire, but sometimes another organization publishes the same artifact under a different name, developers get confused when doing a search and both end up in the project). If you have parent POMs, executions are merged by their id, if the ids differ, there will be multiple executions.
You snipped the important part of the log, which is the line "--- maven-surefire-plugin:2.11:test (tests) # TestClassBlah ---", which includes the plugin artifact ID (maven-surefire-plugin) and execution id (tests). If these lines differ between the two executions, you have your answer.