Develop Reference

Does IntelliJ not utilize Maven's <release> for target byte code level?

I just found out, that IntelliJ behaves very peculiarly when configuring the maven-compiler-plugin with <release> only:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>14</release>
</configuration>
</plugin>
As a result after reloading the Maven project, in the 'Java Compiler' preferences, it displays target bytecode level 8 instead of the expected 14. I guess it was inferred because the modules didn't use any Java 14 features, yet.
see preferences screenshot: https://imgur.com/a/uKfwbfF
In comparison, when adding <source> and <target> the IDE configures its own configuration, correctly.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>14</source>
<target>14</target>
</configuration>
</plugin>
see preferences screenshot: https://imgur.com/a/uKfwbfF
As far as I understand it, the javac --release option is slightly more reliable than just defining -source and -target because it additionally sets the -bootclasspath option to the correct level (double-checked with this SO post). So it seems to me that relying on this option exclusively is a better practice.
Is there another configuration step that I would have to execute in order to make IntelliJ set up the preferences, correctly, without declaring the older parameters?

I investigated that issue a little closer and found out that somewhere in one of the parent poms the maven-compiler-plugin was added to the <pluginManagement> with a maven-property that got never set for the configuration.
This seemed to have caused IntelliJ to infer by language level even though I overwrote the plugin configuration in the child-pom.
I guess that's acceptable behaviour because if the parent pom is faulty, IntelliJ shouldn't try too hard to figure out stuff on its own to just cause more confusion.

Maven + Tycho, adding Maven dependencies

We have an Eclipse Plugin which we build using Maven and Tycho. Currently
however, we still provide all project dependencies through a bunch of manually
added JAR files and not by Maven. This is due to the following reasons: (1) The
dependencies are not available through a standard Eclipse update site (at least
not in a current version), (2) the dependencies are not available as bundles.
The biggest part of these dependencies are the Selenium libraries (API, Remote,
browser-specific libs and their transitive dependencies, such as Guava, etc.)
I've wasted hours, trying to pull those dependencies during our Maven build.
Following this SO question, I tried the p2-maven-plugin, created an update
site with our dependencies which I added to my Eclipse target platform. However,
during runtime, classes, which are referenced across different JARs could not be
loaded (I assume, from my very limited OSGi knowledge, because some
necessary information was missing in the MANIFEST.MF files). Here's an example
of the issue, when trying to create a RemoteWebDriver, which uses the
DesiredCapabilities class (both classes in different bundles):
Exception in thread "Thread-8" java.lang.NoClassDefFoundError: org/openqa/selenium/remote/DesiredCapabilities
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:243)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:126)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:153)
…
Caused by: java.lang.ClassNotFoundException: org.openqa.selenium.remote.DesiredCapabilities cannot be found by org.seleniumhq.selenium.remote-driver_2.45.0
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
Is there anything I still need to take care of, when using the p2-maven-plugin? The relevant parts of the pom.xml looked like this:
<plugin>
<groupId>org.reficio</groupId>
<artifactId>p2-maven-plugin</artifactId>
<version>1.1.1-SNAPSHOT</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<artifacts>
<artifact>
<id>org.seleniumhq.selenium:selenium-remote-driver:2.45.0</id>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>

Couldn't get it to work, so we're now using the maven-dependency-plugin with the copy-dependencies, which we execute during the Maven initialize phase to pull all necessary dependencies (contrary to my initial feeling, this can be combined with the pom.xml using the eclipse-plugin packaging and the "manifest first" approach). The relevant part looks like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>initialize</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<includeScope>runtime</includeScope>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The Maven dependencies are then copied to target/dependency.
Only little issue: The Bundle-ClassPath in the MANIFEST.MF needs to be manually updated in case the name of a JAR file changes when updating Maven dependencies (e.g. commons-io-2.4.jar becomes commons-io-2.5.jar).
[edit] Revisiting this answer in regards to the last sentence above: The version numbers can be conveniently stripped through the following option: <stripVersion>true</stripVersion>. This means, the above library will be renamed to commons-io.jar and thus no paths need to be updated when a version number changes.

Another possibility:
Some jar files may be broken (if you're using Eclipse, it's commonplace hibernate-commons-annotations-4.0.1.Final.jar; invalid LOC header (bad signature)? ). To check this possibility, try manually opening the jar to see if it's okay.

I also build an Eclipse plugin with Maven and Tycho. I have the same problem: the bundle org.eclipse.team.svn.core and org.eclipse.team.svn.ui are not available through a standard Eclipse update site.
Maybe you can try this to solve this kind of problem:
In Dependencies, find the box Automated Management of
Dependencies.
Add the wanted plugin using Add...
Choose Analyze code and add dependencies to the MANIFEST.MF via: Import-Package
Click on Add Dependencies so that you find required packages in the box Imported Packages nearby.
Then you can run the Maven build.

How to have Maven excluded source packages to be reflected in IntelliJ IDEA?

Using maven-compiler-plugin I specified three packages to be ignored from source. However, after importing the project into IntelliJ, those folders are treated as source packages normally, and this happens after every POM reorganization. Needless to say, I have to exclude them manually after every POM change.
I know there was some maven-idea plugin, but I see it has been retired. I use IDEA 13.
How to make IntelliJ IDEA to support packages exclusion based on Maven?
Relevant pom excerpt:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>2.3.2</artifactId>
<configuration>
<excludes>
<exclude>test/**/*</exclude>
<exclude>unused/**/*</exclude>
<exclude>my/test/package/unused/**/*</exclude>
<excludes>
<configuration>
</plugin>
Works fine for Maven build (classes from excluded packages do not compile).

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.

IntelliJ IDEA - Error: java: package foo does not exist

I have a project in IntelliJ IDEA that consists of both Java and Groovy classes. These classes are contained in folders "groovy" and "java" that I've marked as source folders. I have many Java classes that import classes from the "groovy" source folder, but when I try running them, I consistently get the error "java: package foo does not exist". Package "foo" exists directly under the "groovy" folder, so this should be working. I included a visual below. (I'm trying to avoid any specific details. I may or may not be working on a top secret Area 51 project.)
Structure visual:
project-folder
|
-src
|
-main
|
-groovy (marked as source)
||
|-foo
| |
| -bar.groovy
-java (marked as source)
|
- java class that imports "foo.bar"
Error:
java: package foo does not exist
Things that don't work:
Taking everything under "framework" and placing them directly under "groovy" folder. Results in "Cannot resolve symbol bar"
Unmavenizing project and rebuilding

You should not have to "unmavenize" your project. (Although I understand the troubleshooting reasoning for suggesting you do such.) I suspect the issue is a corrupted cache or index. Go to File > Invalidate Cache. Select to invalidate the cache and then restart IDEA. Let IDEA re-index the project. Things should be fine. If not, check that 1) you are using the latest version of IDEA (12.1.5) and 2) the latest version of the Groovy plug-in (File > Settings > [IDE Settings] > Plugins).
When you do use maven, you will need to identify the "groovy" directory as an additional source directory in your POM. If you do not, when IDEA re-imports the project (i.e. re-syncs to the POM), it will drop the groovy directory as a source since by default maven does not consider it a source. How you do this depends on what plugin you use. Since GMaven is no longer maintained, I've been using the groovy-eclipse-compiler plugin. If you use that plug-in, the plug-in will automatically include src/main/groovy as a source (as long as there is at least one java or groovy file in src/main/java). However, IDEA does not pick that directory up and include it as a source as well. That means if you manually (or IDEA automatically) runs a maven re-import, your src/main/groovy directory will get unmarked as a source, and IDEA will show compile errors. You need to specify the additional directory. You can use the build-helper-maven-plugin to do this as the groovy-eclipse-compiler documentation recommends.
Here's the meat & potatoes of a POM for a working Java/Groovy project:
<properties>
<groovy.version>2.1.5</groovy.version>
<groovy-eclipse-compiler.version>2.8.0-01</groovy-eclipse-compiler.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>${groovy-eclipse-compiler.version}</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.1.5-03</version>
<scope>compile</scope>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/groovy</source>
</sources>
</configuration>
</execution>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>src/test/groovy</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>${groovy.version}</version>
</dependency>
</dependencies>

Restart IntelliJ :-) Dumb, but that's what worked for me. No idea what was causing the issue, but I'm glad it's fixed. Hopefully that helps someone else too.

I had the similar problem. In my case, groovy compilation logged RuntimeException as warning. This is because of No suitable classloader found for grab.
After I fixed this issue, groovy sources were successfully compiled and Java classes were able to see them on the classpath.