We Keep Coding

Maven build failing in Flex PMD Report report generation phase

I'm getting the following error while executing the goal com.adobe.ac:flex-pmd-maven-plugin:1.2:report (run-flexpmd-main) in one of the sub modules of our project.
Failed to execute goal com.adobe.ac:flex-pmd-maven-plugin:1.2:report (run-flexpmd-main) on project sample-Project: An error has occurred in Flex PMD Report report generation. A system exception has been thrown: 0 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.adobe.ac:flex-pmd-maven-plugin:1.2:report (run-flexpmd-main) on project sample-Project: An error has occurred in Flex PMD Report report generation.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: An error has occurred in Flex PMD Report report generation.
at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:98)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.reporting.MavenReportException: A system exception has been thrown
at com.adobe.ac.pmd.maven.AbstractFlexPmdMojo.executeReport(AbstractFlexPmdMojo.java:212)
at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117)
at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:92)
... 21 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at com.adobe.ac.utils.StackTraceUtils.print(StackTraceUtils.java:48)
at com.adobe.ac.utils.StackTraceUtils.print(StackTraceUtils.java:66)
at com.adobe.ac.pmd.FlexPmdViolations.processFile(FlexPmdViolations.java:202)
at com.adobe.ac.pmd.FlexPmdViolations.processRule(FlexPmdViolations.java:214)
at com.adobe.ac.pmd.FlexPmdViolations.processRule(FlexPmdViolations.java:224)
at com.adobe.ac.pmd.FlexPmdViolations.processRules(FlexPmdViolations.java:244)
at com.adobe.ac.pmd.FlexPmdViolations.computeViolations(FlexPmdViolations.java:103)
at com.adobe.ac.pmd.engines.AbstractFlexPmdEngine.computeViolations(AbstractFlexPmdEngine.java:161)
at com.adobe.ac.pmd.engines.AbstractFlexPmdEngine.executeReport(AbstractFlexPmdEngine.java:138)
at com.adobe.ac.pmd.maven.AbstractFlexPmdMojo.executeReport(AbstractFlexPmdMojo.java:205)
... 23 more
Below is the goal configuration specified in the pom.xml file:
<plugin>
<groupId>com.adobe.ac</groupId>
<artifactId>flex-pmd-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<failOnError>true</failOnError>
<ruleSet>
${settings.localRepository}/example_dir/flexpmd-rules/${flexPMD_ruleSetVersion}/flexpmd-rules-${flexPMD_ruleSetVersion}.xml
</ruleSet>
</configuration>
<executions>
<execution>
<id>run-flexpmd-main</id>
<phase>process-sources</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<sourceDirectory>${project.build.sourceDirectory}</sourceDirectory>
<outputDirectory>${project.build.directory}/pmd/main</outputDirectory>
</configuration>
</execution>
<execution>
<id>run-flexpmd-test</id>
<phase>process-test-sources</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<sourceDirectory>${project.build.testSourceDirectory}</sourceDirectory>
<outputDirectory>${project.build.directory}/pmd/test</outputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.adobe.flexpmd</groupId>
<artifactId>custom-ruleset</artifactId>
<version>0.0.4</version>
</dependency>
<dependency>
<groupId>example_dir</groupId>
<artifactId>flexpmd-rules</artifactId>
<version>${flexPMD_ruleSetVersion}</version>
<type>xml</type>
</dependency>
</dependencies>
</plugin>
We are using the same set of rules for all the other sub projects and there report is getting generated successfully. Only in one particular project it is throwing error.And we haven't made any changes in the flexpmd ruleset recently. This issue started when we migrated our dependencies to a new artifactory and was testing build after migration. I also tried setting failonError as false, but still it is throwing this error. Can anyone please help us to debug this error?

CDI invalid bean archive scanning in Jetty (not in Tomcat)

I thought I got the most about Weld and CDI but this assumption is always demonstrating false. This time I am facing a weird behavior about bean scanning. Everything (a multi-module maven project) runs fine in Tomcat, but I got problems when it runs in the Maven Jetty 9 plugin:
java.lang.IllegalStateException: WELD-ENV-000033: Invalid bean archive scanning result - found multiple results with the same reference: /home/myuser/workspace/my-root-project/my-web-module/target/classes
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:68)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:329)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp(JettyWebAppContext.java:357)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:432)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:167)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.maven.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:460)
at org.eclipse.jetty.maven.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:328)
at org.eclipse.jetty.maven.plugin.JettyRunMojo.execute(JettyRunMojo.java:170)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.IllegalStateException: WELD-ENV-000033: Invalid bean archive scanning result - found multiple results with the same reference: /home/pezzati/workspace/GI-project/gs-service/target/classes
at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:96)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment(WeldServletLifecycle.java:308)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:159)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:61)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
... 50 more
I searched a lot but I can't find so much about this error. Sadly I can even share poor things about this project. It looks like Jetty scans for beans twice, is that possible? Any help/tip about what this error could be about and how to track it down?
UPDATE
Here is a snippet of the pom.xml regarding Weld:
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet</artifactId>
<version>2.4.1.Final</version>
</dependency>
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se</artifactId>
<version>2.4.1.Final</version>
</dependency>
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>2.4.1.Final</version>
</dependency>
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jandex</artifactId>
<version>2.0.3.Final</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-integration-cdi</artifactId>
<version>3.1.9</version>
</dependency>
jetty-maven-plugin version is 9.4.6.v20170531. The webapp is a simple webapp. It deploy fine on a Jetty 9.4.6 where you activate the cdi module.
UPDATE
I read this and I add the weld-servlet artifact as plugin's dependency:
...
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.6.v20170531</version>
<configuration>
<httpConnector>
<port>${jetty.port}</port>
</httpConnector>
</configuration>
<dependencies>
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet</artifactId>
<version>2.4.3.Final</version>
</dependency>
</dependencies>
</plugin>
...
web.xml does not need any change, but I am facing the same result (weld servlet version match with jar version inside jetty's cdi module directory).

There were quite a few problems with Maven Jetty plugin (mainly strange classloading issues). The plugin was even removed from Weld examples.
The error basically means that Weld found multiple bean archives referencing the same beans.xml.
I believe your application would work fine if deployed to a standalone Jetty. Also a reproducer application or at least some configuration info (Weld version, Jetty version, etc.) and deploymnet structure would be helpful.

Impossible to build project with maven [duplicate]

This question already has answers here:
How do I tell Spring Boot which main class to use for the executable jar?
(11 answers)
Closed 6 years ago.
It is the first time i try to build a project with Maven, and it just doesn't work... I have no idea what to do.
Here are my specs:
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
Maven home: C:\Program Files\Apache\maven
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
Here is the pom.xml:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.stormpath.sample</groupId>
<artifactId>stormpath-spring-boot-spring-security-tutorial</artifactId>
<version>0.1.0</version>
<name>Spring Boot Spring Security Stormpath Tutorial</name>
<description>A simple Spring Boot Web MVC application with Spring Security and out-of-the-box login and self-service screens!</description>
<dependencies>
<dependency>
<groupId>com.stormpath.spring</groupId>
<artifactId>stormpath-default-spring-boot-starter</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>1.4.1.RELEASE</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I run the command: "mvn clean install -e"
and I end up getting this error:
Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:1.4.1.RELEASE:repackage (default) on project stormpath-spring-boot-spring-security-tutorial: Execution default of goal org.springframework.boot:spring-boot-maven-plugin:1.4.1.RELEASE:repackage failed: Unable to find main class -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:1.4.1.RELEASE:repackage (default) on project stormpath-spring-boot-spring-security-tutorial: Execution default of goal org.springframework.boot:spring-boot-maven-plugin:1.4.1.RELEASE:repackage failed: Unable to find main class
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.springframework.boot:spring-boot-maven-plugin:1.4.1.RELEASE:repackage failed: Unable to find main class
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: java.lang.IllegalStateException: Unable to find main class
at org.springframework.boot.loader.tools.Repackager.buildManifest(Repackager.java:291)
at org.springframework.boot.loader.tools.Repackager.repackage(Repackager.java:207)
at org.springframework.boot.loader.tools.Repackager.repackage(Repackager.java:152)
at org.springframework.boot.maven.RepackageMojo.repackage(RepackageMojo.java:206)
at org.springframework.boot.maven.RepackageMojo.execute(RepackageMojo.java:193)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more

Spring Boot can detect your main class when you only have one. You probably have more than one, so Spring Boot can't know which one to use!
Since you are not using spring-boot as parent project, you need to specify the main class in spring-boot-maven-plugin:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>1.4.1.RELEASE</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>com.package.MainClass</mainClass>
</configuration>
</plugin>
If you were declaring spring-boot-starter-parent as your parent project, you could have just delcared the start-class property:
<start-class>com.package.MainClass</start-class>

If I run a plugin from the command line at the root pom, what does it do when traversing modules?

I'm trying to use the plugin: http://gatling.io/docs/2.0.1/extensions/maven_plugin.html
I'm trying to run this command at the root pom:
mvn package gatling:execute
This multi module project only has this plugin defined in one child pom like so:
<plugins>
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>scala-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<args>
<arg>-deprecation</arg>
<arg>-feature</arg>
<arg>-language:postfixOps</arg>
</args>
</configuration>
<executions>
<execution>
<id>scala-compile-first</id>
<phase>process-resources</phase>
<goals>
<goal>add-source</goal>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>scala-test-compile</id>
<phase>process-test-resources</phase>
<goals>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
But when I run this command at the root, it gives this error:
[INFO] ------------------------------------------------------------------------
[INFO] Building root-pom 2.5.210-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- gatling-maven-plugin:2.1.7:execute (default-cli) # root-pom ---
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at io.gatling.mojo.MainWithArgsInFile.runMain(MainWithArgsInFile.java:50)
at io.gatling.mojo.MainWithArgsInFile.main(MainWithArgsInFile.java:33)
Caused by: java.lang.RuntimeException: Can't find the jar matching (.*scala-library.*\.jar)$
at io.gatling.compiler.ZincCompiler$$anonfun$jarMatching$1$2.apply(ZincCompiler.scala:88)
at io.gatling.compiler.ZincCompiler$$anonfun$jarMatching$1$2.apply(ZincCompiler.scala:88)
at scala.Option.getOrElse(Option.scala:120)
at io.gatling.compiler.ZincCompiler$.jarMatching$1(ZincCompiler.scala:88)
at io.gatling.compiler.ZincCompiler$.setupZincCompiler(ZincCompiler.scala:91)
at io.gatling.compiler.ZincCompiler$delayedInit$body.apply(ZincCompiler.scala:106)
at scala.Function0$class.apply$mcV$sp(Function0.scala:40)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:71)
at scala.App$$anonfun$main$1.apply(App.scala:71)
at scala.collection.immutable.List.foreach(List.scala:318)
at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:32)
at scala.App$class.main(App.scala:71)
at io.gatling.compiler.ZincCompiler$.main(ZincCompiler.scala:35)
at io.gatling.compiler.ZincCompiler.main(ZincCompiler.scala)
... 6 more
This is not a scala project, so this is definitely related to the plugin. Running mvn package without gatling:execute works fine.
I do not know enough about maven to be able to troubleshoot this problem because I can't really tell what maven is trying to do here. If it is trying to run gatling at the root, why? That plugin is not defined in the root pom anywhere. My question is:
When you run a plugin at the root of a multi-module project, how does it traverse my project, look for plugins and run them? I'm asking this question abstractly. You don't have to answer in terms of gatling. I just want to understand maven plugins better.
How do I troubleshoot this issue? I think I could add scala to the root pom, but since it would be the first dependency at that level, it seems like it's the wrong approach.
I could also cd into the one child pom that has this plugin and run the command there, but that means I'll only be running package on a piece of the project. Ideally I'd like to run package on the whole project before I run the plugin.

Running maven with a plugin goal like that will run that goal for all project modules, the same as mvn install will install each module. You don't have to define the plugin anywhere - if you specify it on the commandline, it is run.
You correctly bound the execution of that plugin to one or more lifecycle phases, in this case process-resources and process-test-resources. If you run mvn compile, the the process-resources phase will be executed and the add-sources and compile goals will be run for the gatling plugin. Similarly, running mvn test (which is also run when you mvn install) will run the testCompile goal of the gatling plugin.
What you'll want to do is to also bind the execute goal as is exemplified
on the page you linked. If you want everyting packaged first, bind it to the
integration test phase:
<execution>
<phase>integration-test</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
....
</configuration>
</execution>
Note that integration-test comes after package (and somewhere before install), so to run it, execute mvn integration-test or mvn install.

When mvn install fails cryptically -

I have a maven project with unit tests, and I get a large exception trace when running "mvn install". Surprisingly -- this stacktrace actually doesn't result in failure of the task ! It appears that it is related to the availability of Junit libraries...
1) Id like to know how to fix this (obviously) for this project so that the libraries are available and the tests run (yes, Junit4 is in the pom.xml dependencies).
2) What the best way to definitively debug this and find the root cause is ?
3) Why does Maven say "build success" when clearly the surefire utility threw a nasty exception ?
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
Caused by: java.lang.NoClassDefFoundError: Test at
java.lang.Class.getDeclaredMethods0(Native Method) at
java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at
java.lang.Class.getMethod0(Class.java:2670) at
java.lang.Class.getMethod(Class.java:1603) at
org.apache.maven.surefire.util.ReflectionUtils.tryGetMethod(ReflectionUtils.java:57)
at
org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isSuiteOnly(JUnit3TestChecker.java:65)
at
org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isValidJUnit3Test(JUnit3TestChecker.java:60)
at
org.apache.maven.surefire.common.junit3.JUnit3TestChecker.accept(JUnit3TestChecker.java:55)
at
org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:52)
at
org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:80)
at
org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83)
... 9 more Caused by: java.lang.ClassNotFoundException: Test at
java.net.URLClassLoader$1.run(URLClassLoader.java:202) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:190) at
java.lang.ClassLoader.loadClass(ClassLoader.java:306) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at
java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 21 more
POM is below
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>rudolf</groupId>
<artifactId>r1</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>r1</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.3</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derby</artifactId>
<version>10.9.1.0</version>
</dependency>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.4.0a</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
<pluginRepositories>
<pluginRepository>
<id>onejar-maven-plugin.googlecode.com</id>
<url>http://onejar-maven-plugin.googlecode.com/svn/mavenrepo</url>
</pluginRepository>
</pluginRepositories>
</project>

This is definetly a perfect storm of silliness:
1) My Test Classes is not named according to the default surefire regular expressions See related Maven does not find JUnit tests to run. So the tests weren't really running.
2) The Test that DID run was actually doing some JVM hacking, using classes like "Unsafe" - causing a segmentation fault. This segmentation fault mucks with the overall Maven build, corrupting the result of the maven output.
The take home lessons are:
1) (not 100% sure, but it appears ) -- If some odd low level failure occurs in the JVM during a mvn build, one might expect strange results at the end which dont simply indicate errors/failures in the proper manner
2) Default Junit test case for surefire behaviour doesnt just run all #Test methods in a package automatically - classes have to be named appropriately or you have to manually edit the surefire pattern filters.

I've run into a problem like this with TestNG integration tests (fail-safe). A similarly really cryptic error caused me to lose an entire day (argh! - please, Eclipse/TestNG, if you're going to give us errors, make them helpful). In my case it was because the accessor on the test method was private and needed to be public.
I hope someone else find this useful before an entire day is wasted.