In my project I have a configuration such as
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<commandlineArgs>${additionalExecArgs} -jar ${project.build.directory}/someDir/some.jar</commandlineArgs>
<executable>java</executable>
<classpathScope>runtime</classpathScope>
</configuration>
</execution>
</executions>
</plugin>
to start an executable JAR using Maven exec:exec.
The additionalExecArgs property is empty by default.
In NetBeans I can run this goal by specifying the following action in the nbactions.xml file:
<action>
<actionName>run</actionName>
<goals>
<goal>exec:exec</goal>
</goals>
</action>
To debug this goal in NetBeans I've added the following action to the nbactions.xml file:
<action>
<actionName>debug</actionName>
<goals>
<goal>exec:exec</goal>
</goals>
<properties>
<jpda.listen>true</jpda.listen>
</properties>
<activatedProfiles>
<activatedProfile>debug</activatedProfile>
</activatedProfiles>
</action>
So in addition to running exec:exec it sets the NetBeans (?) property jpda.listen to true and activates the Maven profile debug.
I've also added the following Maven profile to my POM:
<profile>
<id>debug</id>
<properties>
<additionalExecArgs>-Xdebug -Xrunjdwp:transport=dt_socket,server=n,address=${jpda.address}</additionalExecArgs>
</properties>
</profile>
With this configuration I can simply run the debug action from the project context menu/ toolbar.
Please note the jpda.address Maven property however. This property seems to get populated by NetBeans somehow.
If I try to run exec:exec with the debug profile in IntelliJ or Eclipse I'm getting an error, likely because the jpda.address Maven property doesn't get set.
E.g. I'm getting the following error in IntelliJ:
/usr/lib/jvm/java-8-oracle/bin/java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:42300,suspend=y,server=n -Dmaven.home=/usr/share/maven -Dclassworlds.conf=/usr/share/maven/bin/m2.conf -Dfile.encoding=UTF-8 -classpath /usr/share/maven/boot/plexus-classworlds-2.x.jar:/opt/idea-IC-141.1010.3/lib/idea_rt.jar org.codehaus.classworlds.Launcher -Didea.version=14.1.3 -Dmaven.repo.local=/home/someUser/.m2/repository exec:exec -P debug
Connected to the target VM, address: '127.0.0.1:42300', transport: 'socket'
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building test-application 0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- exec-maven-plugin:1.4.0:exec (default-cli) # test-application ---
ERROR: transport error 202: connect failed: Verbindungsaufbau abgelehnt
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
The port changes with every call.
I've tried and replaced jpda.address with a fixed address/ port such as 127.0.0.1:8000, but I'm getting the same error and now in NetBeans, too.
So how can I get a similar behavior in IntelliJ and Eclipse as in NetBeans and debug an exec:exec goal using a Maven run configuration directly without having to resort to a remote debugger configuration or such?
It sounds like you can set up a Remote debug configuration in intellij with a Before launch Maven Goal.
Set it up as follows:
Run/Debug Configurations -> Add Remote -> Add Before Launch -> Maven -> specify correct module and goal.
Related
I'm still working on a multi-module maven project which I upgraded from openJDK 15 to openJDK 19. I'm working on a MBP with macOS 13 Ventura.
Before the upgrade the unit test are passing with the maven-surefire-plugin without any problems.
After upgrading to openJDK 19 the mvn clean test command fails with the following error-message.
[INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) # core ---
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[ERROR] Error occurred during initialization of boot layer
[ERROR] java.lang.module.FindException: Module javafx.graphics not found, required by common
I downloaded the files (openJDK 19 and JavaFX 19), unzipped them to a desired location, added an environment variable pointing to the lib directory of the runtime.
I can run the program from IntelliJ without any problems.
My question is, what did I missed in the configuration to get the test running?
My issues are gone with the advice from #Slavomir Jaranowski.
The changed pom looks like
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M7</version>
<configuration>
<!--<skipTests>${skipUnitTests}</skipTests>-->
<testFailureIgnore>false</testFailureIgnore>
<forkCount>1.5C</forkCount>
<reuseForks>true</reuseForks>
<parallel>methods</parallel>
<threadCount>4</threadCount>
<useUnlimitedThreads>true</useUnlimitedThreads>
<perCoreThreadCount>true</perCoreThreadCount>
<reportFormat>plain</reportFormat>
<trimStackTrace>false</trimStackTrace>
<redirectTestOutputToFile>true</redirectTestOutputToFile>
</configuration>
</plugin>
The configuration is not finished yet.
I have a maven build that is extremely slow. I would like to know whether there is a way to profile maven execution in order to find out which are the most time-consuming steps.
Later I will want to compare these times between builds for older versions (which were faster), so they should be ideally in a format that can be compared/diffed/graphed.
This is the quickest possible way:
export MAVEN_OPTS="-Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss,SSS \
-Dorg.slf4j.simpleLogger.showDateTime=true"
mvn test
Results in
MAVEN_OPTS="-Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss,SSS -Dorg.slf4j.simpleLogger.showDateTime=true" mvn test
17:06:07,330 [INFO] Scanning for projects...
17:06:07,447 [INFO]
17:06:07,447 [INFO] ------------------------------------------------------------------------
17:06:07,448 [INFO] Building bimble-server 0.0.1-SNAPSHOT
17:06:07,448 [INFO] ------------------------------------------------------------------------
17:06:07,747 [INFO]
17:06:07,748 [INFO] --- maven-resources-plugin:2.6:resources (default-resources) # bimble-server ---
If you then add that environment variable to your shell's config file (like ~/.bashrc or ~/.profile) you will have those timings every time you use Maven.
Based on info from Stanley Hillner's blog:
Out of the box solution is the takari maven profiler:
https://github.com/takari/maven-profiler
Sample output from its page:
org.apache.maven:maven-core:3.1.2-SNAPSHOT
clean 176ms
org.apache.maven.plugins:maven-clean-plugin:2.5 (default-clean) 176ms
initialize 408ms
org.codehaus.mojo:buildnumber-maven-plugin:1.2 (create-noncanonicalrev) 349ms
org.codehaus.mojo:buildnumber-maven-plugin:1.2 (create-buildnumber) 59ms
generate-sources 408ms
org.codehaus.modello:modello-maven-plugin:1.8.1 (standard) 369ms
org.codehaus.modello:modello-maven-plugin:1.8.1 (standard) 28ms
org.codehaus.modello:modello-maven-plugin:1.8.1 (standard) 11ms
generate-resources 933ms
org.apache.maven.plugins:maven-remote-resources-plugin:1.4 (default) 932ms
process-resources 225ms
org.apache.maven.plugins:maven-resources-plugin:2.6 (default-resources) 224ms
compile 4s 522ms
org.apache.maven.plugins:maven-compiler-plugin:2.5.1 (default-compile) 4s 522ms
process-classes 6s 880ms
org.codehaus.mojo:animal-sniffer-maven-plugin:1.6 (check-java-1.5-compat) 5s 814ms
org.codehaus.plexus:plexus-component-metadata:1.5.5 (default) 946ms
org.sonatype.plugins:sisu-maven-plugin:1.1 (default) 120ms
process-test-resources 173ms
org.apache.maven.plugins:maven-resources-plugin:2.6 (default-testResources) 173ms
test-compile 818ms
org.apache.maven.plugins:maven-compiler-plugin:2.5.1 (default-testCompile) 818ms
process-test-classes 134ms
org.codehaus.plexus:plexus-component-metadata:1.5.5 (default) 110ms
org.sonatype.plugins:sisu-maven-plugin:1.1 (default) 23ms
test 11s 306ms
org.apache.maven.plugins:maven-surefire-plugin:2.12 (default-test) 11s 306ms
package 1s 371ms
org.apache.maven.plugins:maven-jar-plugin:2.4 (default-jar) 502ms
org.apache.maven.plugins:maven-site-plugin:3.3 (attach-descriptor) 869ms
https://github.com/jcgay/maven-profiler is a similar handy tool. It's easy to setup and use. (Having something like it or EventSpy takari/maven-profiler in core Maven as an option would certainly be neat; comment in https://issues.apache.org/jira/browse/MNG-4639 ..)
This functionality has been included in Maven3. Here's the associated ticket: https://issues.apache.org/jira/browse/MNG-4639
If you need to do the same with Maven2 I'd recommend building yor own plugin that is hooks into all phases of execution ( or just the ones you need to track).
i just create a gist here : https://gist.github.com/boly38/7316378
This is a sample example on how to log datetime of some maven lifecycle steps.
Of course you could adapt this sample to set your own output format (and graph it ...).
Hope this help
Extract :
<profile>
<id>stats</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>log_validate</id>
<phase>validate</phase>
<goals><goal>run</goal></goals>
<configuration>
<tasks>
<tstamp><format property="stepTstamp" pattern="dd-HH:mm:ss" locale="en,US" /></tstamp>
<echo file="stats.log" append="true"
message="${line.separator}${line.separator}${stepTstamp} validate${line.separator}"/>
</tasks>
</configuration>
</execution>
(...)
<execution>
<id>log_process_sources</id>
<phase>process-sources</phase>
<goals><goal>run</goal></goals>
<configuration>
<tasks>
<tstamp><format property="stepTstamp" pattern="dd-HH:mm:ss" locale="en,US" /></tstamp>
<echo file="stats.log" append="true"
message="${stepTstamp} process-sources${line.separator}"/>
</tasks>
</configuration>
</execution>
(...)
My project enforces strict style so I have the maven-checkstyle-plugin running as part of my build.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${maven-checkstyle.version}</version> // 3.0.0
<executions>
<execution>
<id>checkstyle</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<configLocation>google_checks.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>true</failsOnError>
</configuration>
</execution>
</executions>
</plugin>
When I run the build, I see the plugin running and checking style but it should fail when there are checkstyle issues since I have the true flag set.
Any reason it keeps going and the build succeeds?
[INFO] --- maven-checkstyle-plugin:3.0.0:check (checkstyle) # demo-api ---
[INFO] Starting audit...
...
...
[WARN] /Users/jeeves/git/jeeves/demo/src/main/java/com/demo/api/routes/UserRoutes.java:9:57: Parameter name 'BASE_PATH' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$'. [ParameterName]
[WARN] /Users/jeeves/git/jeeves/demo/src/main/java/com/demo/api/routes/UserRoutes.java:13: Line is longer than 100 characters (found 102). [LineLength]
Audit done.
...
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.153 s
[INFO] Finished at: 2018-08-24T09:53:57-04:00
[INFO] Final Memory: 37M/806M
[INFO] ------------------------------------------------------------------------
Read the log:
[WARN] /Users/jeeves/git/jeeves/demo/src/main/java/com/demo/api/routes/UserRoutes.java:9:57: Parameter name 'BASE_PATH' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$'. [ParameterName]
[WARN] /Users/jeeves/git/jeeves/demo/src/main/java/com/demo/api/routes/UserRoutes.java:13: Line is longer than 100 characters (found 102). [LineLength]
Audit done.
Those are warnings and not the errors, so <failsOnError>true</failsOnError> will not trigger.
Adding the following lines into configuration should change the behavior:
<violationSeverity>warning</violationSeverity>
<failOnViolation>true</failOnViolation> <!-- defaults as true, can be omitted -->
See the documentation of maven-checkstyle-plugin-2.16:
violationSeverity defines the level of violation severity.
failOnViolation triggers "fail" event when the violation occurs.
I have a large JEE Maven Multi module project, and share a custom set of rules and suppressions for Checkstyle via build-tools module. I find very hard to release a stable version of this build-tools due to the testing of this same module.
Each time I run a Maven phase, I get a different execution result.
This is Checkstyle configuration in parent pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${checkstyle.plugin.version}</version>
<configuration>
<skip>${skipQATests}</skip>
<configLocation>qa/checkstyle_rules.xml</configLocation>
<propertiesLocation>${checkstyleDir}/checkstyle.properties</propertiesLocation>
<suppressionsLocation>qa/suppressions.xml</suppressionsLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>true</failsOnError>
<failOnViolation>true</failOnViolation>
<linkXRef>false</linkXRef>
</configuration>
<executions>
<execution>
<id>checkstyle-compile</id>
<phase>compile</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I'm trying to find a pattern in the executions, project is set to fail in one particular check and I cannot find the 'bug'.
I execute compile maven phase (mvn clean compile) and it fails on the given check.
I execute package maven phase (mvn clean package) and it fails too.
I execute again compile phase (mvn clean compile) and it doesn't fail (all SUCCESS)
I execute again package and it fails
It does not fail for a couple of runs and then it fails again on some different execution
I know this behavior is kind of difficult to trace without all project information. But is there any kind of procedure, log, tool that would give more information on debuging this problem so that I can determine if it's a bug or some mis-configuration??
Thanks in advance!!
UPDATE:
I have just executed the same mvn command twice on the sub-module I'm testing Checkstyle (test that forces a rule violation) - mvn checkstyle:check -X
Result was different from each other, the main differences are that the CORRECT EXECUTION (the one that fails the build does not find the files at the first try) and the WRONG EXECUTION (the one that ends in SUCCESS finds the configuration files at the first attempt)
EXEC_1: ...
[DEBUG] The resource 'qa/suppressions.xml' was not found with resourceLoader org.codehaus.plexus.resource.loader.FileResourceLoader.
[DEBUG] The resource 'qa/suppressions.xml' was found as jar:file:/C:/Users/usuario/.m2/repository/com/company/tools/build-tools/0.0.2-SNAPSHOT/build-tools-0.0.2-SNAPSHOT.jar!/qa/suppressions.xml.
[DEBUG] Adding the outputDirectory file:/C:/LAB/PRJ/prj-ejbws/target/classes/ to the Checkstyle class path
[DEBUG] The resource 'qa/checkstyle_N4_JEE.xml' was not found with resourceLoader org.codehaus.plexus.resource.loader.FileResourceLoader.
[DEBUG] The resource 'qa/checkstyle_N4_JEE.xml' was found as jar:file:/C:/Users/usuario/.m2/repository/com/company/tools/build-tools/0.0.2-SNAPSHOT/build-tools-0.0.2-SNAPSHOT.jar!/qa/checkstyle_JEE.xml.
[DEBUG] The resource 'ubic.properties' was found as C:\LAB\PRJ\ubic.properties.
[INFO] Starting audit...
[INFO] --------------------------------------------
[INFO] BUILD FAILURE
[INFO] --------------------------------------------
[INFO] Total time: 1.542s
[INFO] Finished at: Thu Feb 20 16:35:22 CET 2014
[INFO] Final Memory: 8M/20M
[INFO] --------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check (default-cli) on project GestionDelContacto-opsa-ejbws: Failed during checkstyle execution: There are 2 checkstyle errors.
EXEC_2:...
[DEBUG] The resource 'qa/suppressions.xml' was found as jar:file:/C:/Users/usuario/.m2/repository/com/company/tools/build-tools/0.0.2-SNAPSHOT/build-tools-0.0.2-SNAPSHOT.jar!/qa/suppressions.xml.
[DEBUG] Adding the outputDirectory file:/C:/LAB/PRJ/prj-ejbws/target/classes/ to the Checkstyle class path
[DEBUG] The resource 'qa/checkstyle_N4_JEE.xml' was found as jar:file:/C:/Users/usuario/.m2/repository/com/company/tools/build-tools/0.0.2-SNAPSHOT/build-tools-0.0.2-SNAPSHOT.jar!/qa/checkstyle_JEE.xml.
[DEBUG] The resource 'ubic.properties' was not found with resourceLoader org.codehaus.plexus.resource.loader.ThreadContextClasspathResourceLoader.
[DEBUG] The resource 'ubic.properties' was not found with resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader.
[DEBUG] The resource 'ubic.properties' was found as C:\LAB\PRJ\ubic.properties.
[INFO] Starting audit...
[INFO] --------------------------------------------
[INFO] BUILD SUCCESS
[INFO] --------------------------------------------
[INFO] Total time: 1.570s
[INFO] Finished at: Thu Feb 20 16:37:05 CET 2014
[INFO] Final Memory: 8M/20M
[INFO] ---------------------------------------------
any clue?
Stop using Maven, run CheckStyle separately. You already have sufficient "clues": sometimes Maven initializes CheckStyle correctly, sometimes not, and depending on unreliable infrastructure is a bad idea.
I've tried for days to use jboss-as-maven-plugin to deploy web projects to remote JBoss AS7, but it didn't work.
Here is my pom.xml:
<!-- JBoss Application Server -->
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.1.0.CR1b</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
<!-- Only remote server needs -->
<configuration>
<hostname>192.168.1.104</hostname>
<port>9999</port>
<username>admin</username>
<password>admin123</password>
</configuration>
</execution>
</executions>
</plugin>
Using this configuration I can deploy to localhost without <configuration>, even no <username> and <password>.
To deploy to my real IP address, I modified ${JBOSS_HOME}/configuration/standlone.xml, by changing jboss.bind.address from 127.0.0.1 to 0.0.0.0 (to unbind JBoss address), so I can deploy projects by using:
<configuration>
<!-- 192.168.1.106 is my ip -->
<hostname>192.168.1.06</hostname>
<port>9999</port>
</configuration>
It works too, but by changing <hostname> to point to my other computer (in the same router) it doesn't work but that computer receives a request, and the request is cut by something. (I thought it may be JBoss)
The error message in Maven console is as follows:
INFO: JBoss Remoting version 3.2.0.CR8
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 30.572s
[INFO] Finished at: Fri Feb 10 23:41:25 CST 2012
[INFO] Final Memory: 18M/170M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.1.0.
CR1b:deploy (default) on project MessagePushX-RELEASE: Could not execute goal de
ploy on MessagePush.war. Reason: java.net.ConnectException: JBAS012144: Could no
t connect to remote://192.168.1.104:9999. The connection timed out -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Who can tell me is JBoss as 7.1.0 is not allowed remote deploy?
For some security issues?
It is definitely not a security issue.
The plugin you are referring uses the JBoss AS7 ability to deploy applications using the Server Deployment Manager (this is new feature in AS7). Previously the deployment was only possible via JMX console, which required the deployment artifact to be reachable by server (local file or URL).
You need to make sure:
192.168.1.104 is running JBoss AS7 with Server Deployment Manager listening on port 9999.
The port should not be bound to localhost iface (not 127.0.0.0:9999 but *:9999).
There is no firewall between you and 192.168.1.104 rejecting packets to port 9999.
what worked for me was to change from jboss-as plugin to wildfly plugin:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.1.0.Alpha8</version>
</plugin>
and then using the maven command:
mvn wildfly:deploy
reference: https://issues.jboss.org/browse/WFLY-3684
For me it worked when configuring the plugin with the hostname parameter "127.0.0.1" as the server seems to bind to that IP by default:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.3.Final</version>
<configuration>
<hostname>127.0.0.1</hostname>
</configuration>
</plugin>
</plugins>
</build>
I solved this problem, using the last version of plugin:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.5.Final</version>
</plugin>
Remote deployment definitely works.
Be sure that management port (native) is bound to *.9999, as mentioned above .
<socket-binding name="management-native" interface="management" port="${*:9999}"/>
Be sure that you added user to management realm. Also, I noticed that password was cached the first time I ran plugin, so later on it keep using stale password (from first run) instead of new one. I notice this using mvn -X option.
I also turned off firewall on jboss server host machine. At least ports 8787, 4447, 8080, 9990 must be opened.
Here is complete plugin declaration
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.6.Final</version>
<executions>
<execution>
<goals>
<goal>deploy</goal>
</goals>
<phase>install</phase>
</execution>
</executions>
<configuration>
<force>true</force>
<hostname>IP</hostname>
<port>9999</port>
<username>mvndeploy</username>
<password>pa##word1.</password>
<filename>${project.build.finalName}</filename>
</configuration>
</plugin>
Test everyting with :
mvn package jboss-as:deploy
Use wildfly-maven-plugin instead of jboss-maven-plugin.
For me worked changing the version of the maven plugin to the newer:
<version>7.1.0.Final</version>
When I got the same error by using IntelliJ I undeployed the project from JBoss server and again deployed it is working fine.
This issue usually occurs due to binding address of your JBOSS, if you will take a look at standlone.xml the jboss management bind address is
jboss.bind.address.management:127.0.0.1
You can change it to the machine IP adress or point it to 0.0.0.0
jboss.bind.address.management:0.0.0.0/machine IP
restart JBOSS and try mvn jboss plugin should work like a charm.