Develop Reference

How does maven knows which plugin needs to invoke from the goal?

Let's say
when you call mvn archetype:generate how does maven knows that it needs to invoke "Maven Archetype Plugin"?
Or when you do mvn dependency:copy-dependencies how does it invoke 'Apache Maven Dependency Plugin'?
i.e How does maven maintains the link between 'archetype' -> 'Maven Archetype Plugin'?

It's available by default. This page lists the core plugins and others
https://maven.apache.org/plugins/.
If you want to use other plugin, you need to mention in pom.xml file, so that the dependencies can be resolved.
<build>
<plugins>
<!--Restdocs config for collating all snippets start-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>XXX</version>
...
</plugin>
</plugins>
</build>
If you run the command mvn animal-sniffer:check. animal-sniffer is the plugin prefix and check is the goal. The mapping between prefix and dependency is mentioned here. Meanwhile, the goal check is mapped by annotation in actual implementation, if you check the source code of this plugin, you will see something like below.
#Mojo( name = "check", defaultPhase = LifecyclePhase.PROCESS_CLASSES, requiresDependencyResolution = ResolutionScope.COMPILE, threadSafe = true )

List actually used maven plugins in XML format for pom

It is an often helpful practice to declare the versions of all used maven plugins in the pom.xml, e.g. to make old builds reproducible after a new plugin version comes out. For a fresh project: is there a way to output the plugins currently used in the build in the XML-format I could easily put into the pluginManagement section of the pom.xml?
I found that versions:display-plugin-updates does output the plugins with versions that are not yet fixed, and help:effective-pom does display the actually used versions implicitly in <build><plugins>, but garbled with the configuration, executions and other information not needed for the pluginManagement section. So I'm looking for something easier - just like mvn -DoutputXML=true dependency:analyze does for dependencies.

How about parsing the output of help:effective-pom ?
With grep for a quick-and-dirty solution :
$ mvn help:effective-pom -Doutput=effective-pom.xml
$ grep "<plugin>" -A 3 effective-pom.xml
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-5</version>
</plugin>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
</plugin>
[...]
Or with an XML Parser and the use of XSLT or XQuery for a more robust solution.
For example, the following XQuery code
declare default element namespace "http://maven.apache.org/POM/4.0.0";
string-join(
for $plugin in //plugin
return string-join(($plugin/groupId/text(), $plugin/artifactId/text(), $plugin/version/text()), ":"),
"
"
)
Will produce this kind of output :
<?xml version="1.0" encoding="UTF-8"?>maven-antrun-plugin:1.3
maven-assembly-plugin:2.2-beta-5
maven-dependency-plugin:2.8
maven-release-plugin:2.3.2
maven-source-plugin:3.0.1
maven-clean-plugin:2.5
maven-install-plugin:2.4
maven-deploy-plugin:2.7
maven-site-plugin:3.3
Note that the xml header could be removed with the appropriate configuration.

GWT CodeServer incremental compilation issue with maven and the new packaging gwt-app and gwt-lib

I've been toying around with the latest changes in the gwt-maven-plugin. Most notably, the new packagings gwt-app and gwt-lib.
To my understanding, if I have some code that I'd like to reuse between different GWT apps, gwt-lib packages all needed sources and *.gwt.xml files in the jar right next to all classes. It works like a charm.
If I opt for a multi-module maven reactor build, everything is detected on compile time and I'm able to build and deploy successfully without any hassle. If I try to develop however, the shiny GWT 2.7 SuperDevMode is unable to detect changes in the gwt-lib projects, obviously because they are referenced from the jars and not the actual sources directory where they were changed.
To illustrate, I used the modular-requestfactory archetype by Thomas Broyer.
mvn archetype:generate \
-DarchetypeCatalog=https://oss.sonatype.org/content/repositories/snapshots/ \
-DarchetypeGroupId=net.ltgt.gwt.archetypes \
-DarchetypeArtifactId=modular-requestfactorcom.testy \
-DarchetypeVersion=1.0-SNAPSHOT
and I entered the following information:
Define value for property 'artifactId': : mvngwt
Define value for property 'version': 1.0-SNAPSHOT: :
Define value for property 'package': com.test: :
Define value for property 'module': App: : MvngwtApp
Define value for property 'module-short-name': mvngwtapp: :
Afterwards I created an additional maven module called "mvn-gwt-client-api", which contains a single class that is to be used by the mvn-gwt-client. The end structure looks like this:
mvngwt/
--mvngwt-client/
--mvngwt-client-api/
--mvngwt-server/
--mvngwt-shared/
--pom.xml
The goal is to be able to edit the files in mvngwt-client-api (e. g. the only class currently: MvngwtApi.java), then recompile in SuperDevMode and actually see the changes immediately without restarting the CodeServer.
A working copy of the project can be found here: https://github.com/elnicko/maven-gwt-test
PS: I tried to work it out with the build-helper-maven-plugin:
<profiles>
<profile>
<!-- elnicko: add to support CodeServer hot compile for referenced libraries -->
<id>env-dev</id>
<activation>
<property>
<name>env</name>
<value>dev</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-shared-sources-to-classpath</id>
<!--
<phase>process-classes</phase>
<phase>compile</phase>
-->
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/../mvngwt-client-api/src/main/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
However it didn't improve the situation.
Any hints/pointers/ideas greatly appreciated.
Edit:
I am able to use the SuperDevMode incremental compilation by using the aforementioned build-helper-maven-plugin configuration, changing the mvngwt-client-api packaging from "gwt-lib" to "jar", and adding a "maven-source-plugin". That way maven compilation and deployment work the same way, but the CodeServer is made aware of the changes in the source directory of mvngwt-client-api. Nevertheless, the question remains open, how one can use the new "gwt-lib" without losing the CodeServer incremental compilation. The diff may be seen here: https://github.com/elnicko/maven-gwt-test/compare/master...working_wihtout_gwt-lib_but_with_jar_packaging

You have to use <type>gwt-lib</type> in your dependency.
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>mvngwt-client-api</artifactId>
<version>${project.version}</version>
<type>gwt-lib</type>
</dependency>
Actually, if you run Maven with -X you'll see in the logs:
[DEBUG] Adding sources for com.test:mvngwt-client:gwt-app:1.0-SNAPSHOT
[DEBUG] Ignoring com.test:mvngwt-shared:jar:1.0-SNAPSHOT; neither a java-source, gwt-lib or jar:sources.
[DEBUG] Adding sources for com.test:mvngwt-shared:jar:1.0-SNAPSHOT
[DEBUG] Ignoring com.test:mvngwt-client-api:jar:1.0-SNAPSHOT; neither a java-source, gwt-lib or jar:sources.
[DEBUG] Ignoring com.google.gwt:gwt-user:jar:2.7.0; neither a java-source, gwt-lib or jar:sources.
[DEBUG] Ignoring com.google.gwt:gwt-dev:jar:2.7.0; neither a java-source, gwt-lib or jar:sources.
[DEBUG] Ignoring com.google.gwt:gwt-codeserver:jar:2.7.0; neither a java-source, gwt-lib or jar:sources.
Maybe those should be emitted at INFO level rather than DEBUG…
BTW, instead of the build-helper-maven-plugin, you could have just used a <type>java-source</type> or <classifier>sources</classifier> dependency, like it's done for the mvngwt-shared module.

tell grails maven plugin to use servlet 2.5 instead of 3.0

I might have a stupid and really obvious question:
I basically have a grails 2.3.8 project, build using maven 3.2, with the grails maven plugin 2.4.3
<plugin>
<groupId>org.grails</groupId>
<artifactId>grails-maven-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<!-- Whether for Fork a JVM to run Grails commands -->
<fork>true</fork>
<grailsVersion>${grails.version}</grailsVersion>
</configuration>
<extensions>true</extensions>
</plugin>
when I do a
mvn clean install
I keep getting the following exception:
java.lang.NoClassDefFoundError: javax/servlet/AsyncContext
at java.lang.Class.privateGetDeclaredMethods(Class.java:2484)
at java.lang.Class.getDeclaredMethods(Class.java:1827)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
my BuildConfig specifies grails to utilize, servlet 2.5
grails.servlet.version = "2.5"
and all my test's are working fine, if I run them from grails directly using:
grails test-app :integration
but fail with the given exception, if I run them from the command line
mvn clean install
my dependency report lists the correct servlet version:
javax.servlet:servlet-api:jar:2.5:provided
anybody has an idea how to solve this?
thanks

How to fix Maven PermGen out of memory error on Travis-ci?

I'm getting PermGen out of memory error on every build at travis-ci. This is my configuration file:
language: java
env:
global:
- MAVEN_OPTS="-XX:MaxPermSize=512m -Xmx4g"
script: mvn clean install
Looks like MAVEN_OPTS is not working, since the same values on another server make the build successful.
Here is one of the builds: https://travis-ci.org/tpc2/requs/builds/23383360

Your build link is no longer valid, so I'm going to make a guess. Are you getting the PermGen during surefire tests? That plugin uses a separately configured arg line. Our builds are configured like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.14.1</version>
<configuration>
<argLine>${argLine} -Xmx512m -XX:MaxPermSize=256m</argLine>
</configuration>
</plugin>

You can set JVM memory settings in MAVEN_OPTS by adding this to .travis.yml:
before_install: echo "MAVEN_OPTS='-Xmx2048m -XX:MaxPermSize=512m'" > ~/.mavenrc