Intellij: skipTests flag not recognized - maven

I got the following maven configuration in my pom.xml The skipTests variable is highlighted red by Intellij Ultimate 2018.1 as
Cannot resolve symbol 'skipTests'
But why? This is a common maven environmental variable.
<build>
<plugins>
<plugin>
<!-- exec yarn -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
...
<execution>
<id>yarn-test</id>
<phase>process-test-classes</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>yarn</executable>
<skip>${skipTests}</skip>
<arguments>
<argument>test</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

I solved the issue by putting the intellij ignore comment
<!--suppress MavenModelInspection -->
on that particular pom line.

Try to restart Intellij Idea, sometimes the errors disappear only when you restart it. If that doesn't work, try to change the version of your Maven.
EDIT
Check this link, I think that will help you How to disable pom.xml validation in IntelliJ IDEA

Related

Why does exec-maven-plugin run all phases twice?

When I run a build with maven using the exec-maven-plugin, it runs everything twice for some reason. Is there a way to fix this so it only runs once? I've tried setting my phase in the pom.xml to compile and package and either way, it runs twice. My pom looks like
<build>
<plugins>
<plugin>
<artifactId>exec-maven-plugin</artifactId>
<groupId>org.codehaus.mojo</groupId>
<version>1.0</version>
<executions>
<execution>
<id>foo</id>
<phase>compile</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>bash</executable>
<commandlineArgs>myscript.sh</commandlineArgs>
</configuration>
</plugin>
</plugins>
</build>
It turned out that adding the phase tag caused the command to get executed twice. Leaving that out, it is now getting run once as expected. I guess it doesn't matter what phase I give it now, it'll always run the goal, which works for me.
If you need to run this early in the build, excluding the phase isn't an option.
You can do something like this instead in the plugin config:
<executions>
<execution>
<id>default</id>
<phase>none</phase> <!-- disable the default execution in validate phase -->
</execution>
<execution>
<id>exec-do-something</id>
<goals>
<goal>java</goal>
</goals>
<phase>generate-sources</phase><!-- now it will run once but in an earlier phase -->
</execution>
</executions>
I saw this happening due to the inclusion of:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
This seems to be that the maven-source-plugin causes a re-execution of the generate-sources phase. See https://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html
Invokes the execution of the lifecycle phase generate-sources prior to executing itself.
If I removed this plugin, the exec goal only executed once.

Could not lookup required component: java.util.NoSuchElementException

I started testing a Maven plug-in via the maven-invoker-plugin, and am stuck with a weird exception:
[ERROR] Failed to execute goal my.company:plugin:1.0.4-SNAPSHOT:goal on project org.acme.simple: Could not lookup required component: java.util.NoSuchElementException
[ERROR] role: my.company.plugin.SomeClass
I added the maven-invoker-plugin like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-invoker-plugin</artifactId>
<version>2.0.0</version>
<configuration>
<pomIncludes>
<pomInclude>simple/pom.xml</pomInclude>
</pomIncludes>
<cloneProjectsTo>${project.build.directory}/it</cloneProjectsTo>
<settingsFile>src/it/settings.xml</settingsFile>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>install</goal>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
I -erm- borrowed the settings.xml from this Maven plug-in. And what fails in the pom.xml to be tested is this call:
<plugin>
<groupId>my.company</groupId>
<artifactId>plugin</artifactId>
<version>#project.version#</version>
</plugin>
After some more digging around, I figure that Tycho is at least part of the problem:
<packaging>eclipse-plugin</packaging>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-maven-plugin</artifactId>
<version>0.22.0</version>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
If I remove #project.version# it works, but it's evidently not the current version of the plug-in that is tested. So I guess I have to leave it in. I tried adding maven-compat (as suggested here), but it didn't do anything.
The same exception is displayed when I don't add the plug-in in the pom.xml, but call it via:
invoker.goals=${project.groupId}:${project.artifactId}:${project.version}:goal
Any advice how to handle that problem?
Evidently this plug-in got lost somehow, adding it again made the exception go away:
<plugin>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-component-metadata</artifactId>
<version>1.5.5</version>
<executions>
<execution>
<goals>
<goal>generate-metadata</goal>
<goal>generate-test-metadata</goal>
</goals>
</execution>
</executions>
</plugin>

Redirecting the nexus-staging-maven-plugin to an internal repository

I have a webjars project that I'd like to build snapshots and have them deployed locally (within our infrastructure) but have the releases be managed by webjars.org.
https://github.com/webjars/oscar/blob/15.0.0-RC1/pom.xml
The problem I'm facing is that they need the nexus-staging-maven-plugin defined as part of their release process. So I'd like to keep the POM tailored for them as much as possible, and just make our own deviations via command line (or worst case, profile) if possible.
Typically, if doing this from scratch, you'd probably introduce the staging plugin in a profile, but I don't think I have that option. (I might have to make the modification though and discuss it with them.)
I've never used the staging plugin before, so this is my first exposure and it isn't a pleasant one given what I'm trying to do. I feel like I'm fighting the system.
I thought I had something by specifying:
-DsonatypeOssDistMgmtSnapshotsUrl=http://myurl
and that pushes the artifact at the correct location, but then I can't figure out how to supply credentials. (401 unauthorized) I thought specifying the serverId might work, but no.
-DserverId=public-snapshots
http://books.sonatype.com/nexus-book/reference/staging-deployment.html
I then tried creating a profile, where I'd do something like this:
<profile>
<id>disable-staging</id>
<build>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.5</version>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
but that doesn't help. The effective-pom shows this:
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.5</version>
<extensions>true</extensions>
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</execution>
</executions>
<configuration combine.self="override">
<executions>
<execution>
<id>injected-nexus-deploy</id>
<phase>none</phase>
</execution>
</executions>
</configuration>
</plugin>
and I can't unbind the deploy phase.
I'm wondering if anyone has any ideas on what to do in this type of scenario?
You can use the Nexus Staging Plugin's property skipNexusStagingDeployMojo to achieve this:
mvn clean package deploy:deploy -DskipNexusStagingDeployMojo=true
-DaltDeploymentRepository=snapshots::default::https://my.nexus.host/content/repositories/snapshots-local
It is important to explicitly invoke package and then deploy:deploy, as otherwise (when only invoking mvn deploy) the default execution of the maven-deploy-plugin is suppressed by the Nexus Staging Plugin (even with the skip set to true).

Can I modify the Maven deploy phase to replace the maven-deploy-plugin with my own plugin?

I'm pretty new to Maven...
What I'm trying to do is skip the maven-deploy-plugin during the deploy phase, while replacing it with my own plugin (i.e. I'm deploying to a non-repository location).
I realize I could do this in multiple other ways, but the boss wants to be able to run:
mvn deploy
To get the results of my current workaround, which is disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase), and manually specifying the custom upload goal from the command line.
I'm currently failing to succeed in my mission with:
<executions>
<execution>
<phase>deploy</phase>
</execution>
</executions>
in the build/plugins/plugin section containing my plugin specification, since the deploy phase is skipped by:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Thanks!
disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase)
This is not correct. Disabling maven-deploy-plugin doesn't disable the entire deploy phase. This is how it should be done (looks like you're doing it already):
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Try this (untested) alternative for disabling the standard deploy plugin:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
I want to build on #yegor256's answer a bit... 8 years, 4 months later!
I found myself here getting into the weeds on some legacy Maven configurations that were full of cruft. Coming from a Maven mindset, albeit some years between now and active hacking, I was re-familiarizing myself with the Maven lifecycle.
TLDR... mvn help:effective-pom is your friend. Use your IDE's tools for viewing the effective POM often (NetBeans makes it easy. I added a keyboard shortcut in IntelliJ.)
In the configuration I was reviewing, the previous developers had created two (2) deploy-file executions, one war, one jar.
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
<execution>
<id>deploy-jar</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
I was aware that these executions would be appended to the default-deploy bound to the deploy phase and observed this behavior in the logs. The default-deploy would run, uploading an empty war file, then the deploy-war would run, uploading, and overwriting, the first war file.
Several options exist.
skip and combine.self="override" (my preference)
As presented, using <skip> as a <configuration> option is viable. It is safe and more portable than setting setting the <phase> to none.
However, it will be inherited by the other executions (certainly as presented). To prevent this, you must explicitly tell your additional <execution> configurations to not inherit.
...
...
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration combine.self="override">
... omitted ...
</configuration>
</execution>
...
...
Override default-deploy
Another option, possibly more verbose and lest esoteric than combine.self="override" is to override the execution of the default-deploy <id> of the plugin.
...
<execution>
<id>default-deploy</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
...
This will not be inherited by the additional <executions>.
Another option
As #yegor256 notes, but in the additional configurations explicitly state <skip>false</skip> to "reset" the inherited <skip> from the plugin.
HTH.

maven execute java command

I want to execute a jar file with parameters from maven. The command I want to execute is listed below. I have the perf4j jar file in the dependency. The times.log file is in they filesystem.
java -jar perf4j-0.9.16.jar times.log
Thanks
You might want to take a look # exec-maven-plugin
first
mvn clean install
than
mvn exec:java -Dexec.mainClass="com.java.App" -Dexec.args="Args"
What do you really want to do ? Using a jar (which is a dependency) to monitor your app ?
Did you took a look at maven exec plugin ?
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
...
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>maven</executable>
<!-- optional -->
<workingDirectory>/tmp</workingDirectory>
<arguments>
<argument>-X</argument>
<argument>myproject:dist</argument>
...
</arguments>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
I had looked at maven exec plugin but wasn't sure how and where to specify the jar file name, hence thanks for your responses, but I was looking at a little more info especially with jar file. With some trial and error the following worked. I had to find the main class to use from the jar file. mvn install runs the file and produces the following output:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>java</goal>
</goals>
<configuration>
<mainClass>org.perf4j.LogParser</mainClass>
<arguments>
<argument>InlineLogging.log</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.perf4j</groupId>
<artifactId>perf4j</artifactId>
</dependency>
</dependencies>

Resources