We Keep Coding

Java 9 compiles fine in maven but not in intellij

I wanted to update my project from java 8 to java 10. Hitting the well known problems of java 9 module system. However after some fiddling, researching and back and forth I was able to compile everything in maven. I added a module-info.java to my project. See also this snippet of my pom.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>10</source>
<target>10</target>
<release>10</release>
<optimize>true</optimize>
<debug>true</debug>
</configuration>
<dependencies>
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
<version>6.2</version>
</dependency>
</dependencies>
</plugin>
However Intellij is reporting 100 errors saying
unnamed module ready package X from both A and B
and similar. I'm using Intellij Community Edition 1018.1.5. I tested it in eclipse photon and there it compiles fine. I think that IntelliJ is putting the maven dependencies differently on the module path/classpath than how maven or eclipse puts them.
However, I'm at a loss and have no idea how to convince IntelliJ to compile my project.

I'd prefer to put this in a comment, since I can't really give an answer until I have more info, but you can't add screenshots to comments. In any case, did you tweak the appropriate settings under File > Project Structure > Project as in:
And also under File > Project Structure > Modules:

Maven War Plugin Websphere

I am trying to get a Rational Application Developer project to run on a websphere server. I am trying to get the maven-war-plugin to work. However, when trying to start the server, websphere can not find the UI Files. I have my plugin here:
<build>
<outputDirectory>${project.basedir}\WebContent\WEB-INF\classes</outputDirectory>
<finalName>${project.name}</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<webXml>/WebContent/WEB-INF/web.xml</webXml>
<webappDirectory>WebContent</webappDirectory>
<source>/codeCoverageUI2/src/</source>
<encoding>utf-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
I feel the issue is with my webappDirectory but I do not know what else to put it to, besides the location of all my UI files.
Anyone have some insight?

I am assuming you are using WebSphere Classic V8 or earlier?
What we recommend because when developing a project in RAD/WDT, WAS Classic requires building the project in a "Single Root" structure. Add the following to your pom:
<build>
<outputDirectory>${project.basedir}\WebContent\WEB-INF\classes</outputDirectory>
<finalName>${project.name}</finalName>
...
This will build your source within the Web content folder. (Make sure you do a Project -> "Maven" -> "Update Project...") then rebuild...

mvn checkstyle:checkstyle uses wrong configuration when using reporting

Im facing the following problem. I have set up my checkstyle with the following configuration:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${checkstyle.plugin.version}</version>
<inherited/>
<configuration>
<configLocation>${basedir}/checkstyle.xml</configLocation>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
</configuration>
</plugin>
</plugins>
</reporting>
This runs fine when I run mvn site. However, when I run checkstyle through mvn checkstyle:checkstyle in order to get the XML report much more efficiently, the checkstyle plugin fails back to use the default configuration. When I move the plugin to <build> the XML is generated properly, but now the checkstyle report is not included in the generated site anymore.
What is the (current) way of setting up report plugins as Checkstyle, while perserving the ability to run the plugin separately under the same configuration?
Is it really the preferred way to defined your plugins and configuration twice?

Okay, apparently you should add the plugin with configuration to both <build> and <reporting>.

Issus with building the java project using maven2

I am using maven2 to build the java project, when i issue the command mvn clean install i am getting the error could not parse error message: (use -source 5 or higher to enable generics).
In my eclipse environment i am using jdk 1.7 and the project is working fine. when i want to build the project i am unable to do that, think maven is taking java version 1.3 as default.
Any one please help me how to set the jdk versio to 1.7 in maven, to build the project successfully..
Apart from the jars mentioned in pom.xml i want to add add my own jar, how can i specify that in pom xml?
Thanks in advance..

In your pom.xml configure the maven-compiler-plugin to use 1.6:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>

default maven compiler setting

Right now, I'm writing a small java application by my own, with few maven pom.xml files. I want to make all my maven packages to compile with jdk 1.6, and I can't find a good way to do it without manually setting it on every single POMs - I'm sick of copy-and-pasting
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
in every single pom.xml file I generate.
Is there a simpler way to resolve this issue?

Create a pom-only (<packaging>pom</packaging>) project that has the compiler settings (and any other default settings) you want. You give treat it like any other project (release it; deploy it to your Maven repo, etc.).
Put a parent declaration at the top of your pom files:
<parent>
<groupId><!-- parent's group id --></groupId>
<artifactId><!-- parent's artifact id --></artifactId>
<version><!-- parent's version --></version>
</parent>
It doesn't help much if all you want to set is compiler settings. But if you find yourself configuring lots of plugins, reports and dependencies in the same way across project, you can create one parent to rule them all.
BTW - be careful about declaring dependencies and plugins in your parent pom file. Usually you'll want to favor dependencyManagement and pluginManagement. See the documentation for more details.

You could specify this plugin and configuration in your ~/.m2/settings.xml, which will then apply it to all projects.
However this has the downside of making your projects no longer portable - attempting to build the same code with the same pom.xml will fail on other machines that don't have the same settings.xml values as you.

I'm sick of copy-and-pasting
Yes, and you should use POM inheritance to avoid this and configure the maven-compiler-plugin in the parent POM.
Another option would be to use the solution suggested by #matt (and he nailed down pros and cons of the use of settings.xml).
In both cases, this is typically a setting that I like to check using the maven-enforcer-plugin and its requireJavaVersion rule that you would configure like this:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireJavaVersion>
<version>1.6</version>
</requireJavaVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
But it can do more (like checking the maven version). Very useful.

I want to make all my maven packages to compile with jdk 1.6
If this is multi-module project just put these settings to top-level POM under pluginManagement.
If you have many independent project just copy-and-paste this configuration. Beware of "smart" solutions like setting this somewhere globally. Some day you will want to use different compiler settings for one or two of your projects and the nightmare will begin :-)
Remember...
Keep things as simple as possible, but no simpler.