On the other side, it presents some complications: The GMavenPlus compiler adds support for features that were still not present in other compilers at the time, such as invokedynamic, the interactive shell console, and Android. To do so, the plugin separates itself from the standard guidelines for compiler plugins. The GMavenPlus plugin may have a name similar to the old GMaven plugin, but instead of creating a mere patch, the author made an effort to simplify and decouple the compiler from a specific Groovy version. To force the file discovery, we could add any file in src/main/java and src/test/java, or simply add the groovy-eclipse-compiler plugin: The same mechanism is valid for our tests. The groovy-all dependency version should match the compiler version.įinally, we need to configure our source autodiscovery: by default, the compiler would look into folders such as src/main/java and src/main/groovy, but if our java folder is empty, the compiler won't look for our groovy sources. In fact, the plugin we'll use – the Maven compiler plugin – doesn't actually compile, but instead delegates the job to the groovy-eclipse-batch artifact: Then, in the plugin section, we tell the Maven compiler which Groovy compiler version it has to use. To enable retrieval of the newest compiler artifacts, we have to add the Maven Bintray repository: The Groovy-Eclipse Maven plugin simplifies the joint compilation by avoiding stubs generation, still a mandatory step for other compilers like GMaven +, but it presents some configuration quirks.
0 kommentar(er)
