I am running a spring integration test using maven. I am trying to run it with debug port enabled so that I can attach to it from IntelliJ idea.
The following command line used to work in the past. It used to allow the surefire bootup to initialize, and then wait to attach to port 8000 before continuing with the test:
-Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 -Xnoagent -Djava.compiler=NONE" -DtestIntegration test
However this is now giving me the following exception:
[ERROR] No plugin found for prefix 'runjdwp' in the current project and in the plugin groups [com.zillow, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/ferozed/.m2/repository-p4), nexus (http://repo.zillow.local/content/groups/public)] -> [Help 1]
org.apache.maven.plugin.prefix.NoPluginFoundForPrefixException: No plugin found for prefix 'runjdwp' in the current project and in the plugin groups [com.zillow, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/ferozed/.m2/repository-p4), nexus (http://repo.zillow.local/content/groups/public)]
at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:93)
at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:260)
at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:220)
at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106)
at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
Any ideas how I can get this to work?
I remember dealing with this before. The debug options you are using may have been deprecated in your version of Java. Java 5 and under used -Xrunjdwp. I believe Java 7 and up (not sure about 6, used both?) use agentlib:jdwp. I recommend checking out this answer on SO.
https://stackoverflow.com/a/173447/50558
None of the plugin approaches (-Xrunjdwp, or -Xagentlib ) worked for me.
So, I gave up and ran the test with -DforkMode=never for the surefire plugin, and that made sure that the test ran in-process with the maven execution. Then I could attach to the process.
I have read elsewhere that this is not safe, as the classpath of the invocation might get shared with the classpath of the test, but I could not find any other way to make my scenario work.
Related
There executes a particular Maven plugin and I struggle to find out where it comes from to either remove or replace it as its compile dependency link is broken. I am talking about org.reflections:reflections-maven:0.9.8 that depends on org.jfrog.jade.plugins.common:jade-plugin-common:1.3.8 which Maven is not able to download from the central repository as the link redirects to OpenMind location and results in 404 (link).
Instead of including such JAR in the project structure, I would rather figure out where is reflections-maven plugin defined as this plugin is discontinued (GitHub) but somehow is executed during the build (mvn clean install).
[INFO] --- reflections-maven:0.9.5:reflections (default) # my-module ---
[INFO] Reflections took 240 ms to scan 1 urls, producing 35 keys and 128 values
[INFO] Reflections successfully saved in C:\Dev\my-project\my-parent\my-module\target\classes\META-INF\reflections\my-module-reflections.xml using XmlSerializer
I haven't found where is reflections-maven defined in any of the multi-module project structure or used. Note I use Maven 3.3.9. My attempts:
Skimming through all plugins and dependencies pom.xml of the failing module and all its parents (the module depends on other modules, however, they were all built successfully before the failing one).
mvn dependency:tree -Dverbose doesn't mention any of reflections-maven or jade-plugin-common at all. The command generates over 136k lines, so it was required to save the output into a file and perform the full-text-search. I am afras Maven 3 is the limit here as far as I understand from this comment.
Using depgraph-maven-plugin gave me the very same negative result.
mvn dependency:analyze -DignoreNonCompile gives only an information that the artifacts were resolved and that where it ends. it doesn't really show anything useful.
[INFO] --- reflections-maven:0.9.5:reflections (default) # my-module ---
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.reflections:reflections-maven:pom:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\reflections\reflections-maven\0.9.5\reflections-maven-0.9.5.pom-[IJ]-artifactCoord=org.reflections:reflections-maven:pom:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.reflections:reflections-maven:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\reflections\reflections-maven\0.9.5\reflections-maven-0.9.5.jar-[IJ]-artifactCoord=org.reflections:reflections-maven:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.reflections:reflections:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\reflections\reflections\0.9.5\reflections-0.9.5.jar-[IJ]-artifactCoord=org.reflections:reflections:jar:0.9.5-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=com.google.guava:guava:jar:r08-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\com\google\guava\guava\r08\guava-r08.jar-[IJ]-artifactCoord=com.google.guava:guava:jar:r08-[IJ]-error=
...
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.4.0-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\jfrog\maven\annomojo\maven-plugin-anno\1.4.0\maven-plugin-anno-1.4.0.jar-[IJ]-artifactCoord=org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.4.0-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVING-[IJ]-path=-[IJ]-artifactCoord=org.jfrog.jade.plugins.common:jade-plugin-common:jar:1.3.8-[IJ]-error=
[IJ]-1-ARTIFACT_RESOLVED-[IJ]-path=C:\Users\user\.m2\repository\org\jfrog\jade\plugins\common\jade-plugin-common\1.3.8\jade-plugin-common-1.3.8.jar-[IJ]-artifactCoord=org.jfrog.jade.plugins.common:jade-plugin-common:jar:1.3.8-[IJ]-error=
...
Checking the artifacts using the reflections-maven from here, however, none of the artifacts mentioned appear in my project as well.
Question: If I don't have such JAR in the local repository, the build fails as the plugin is executed. In that case, how can I find a way any plugin (particularly reflections-maven in my case) is truly imported and executed in the project?
Feel free to ask for more info in the commens. I use IntelliJ Idea, Maven 3.3.9 and Java 7 if it matters.
Solution 1 (didn't work for me): I have tried to run mvn -Dverbose=true -Doutput=./effective-pom.xml help:effective-pom and both the normal and the verbose form of effective-pom displays the same output of reflections-maven plugin with no additional information about its origin. Since the file is rather big, I include a screenshot:
This might be an issue with my Maven 3.3.9 with a custom settings.xml and a specific IntelliJ Idea. I assume the verbose output would lead to the true origin.
Solution 2:
Upon installing Netbeans (I use IntelliJ Idea by default), the Effective tab of the POM editor finally led me to the true origin where the plugin is defined.
Sadly, IntelliJ Idea doesn't provide such navigation through its effective POM and navigating to the origin is virtually impossible without manual clicking through parent POMs.
With
Help:Effective-Pom:
mvn -Dverbose=true -Doutput=./effective-pom.xml help:effective-pom
We can analyze our "effective pom" (Pom#inheritance, Pom#super-Pom).
The verbose flag will also add the source pom (artifact) as a comment to each output line.
output sets an output file. (default: prints to console)
"inter alia" it allows us to locate/override any inherited plugin/dependency/"pom element".
Unfortunately the output generates:
for "trivial" projects "hundreds" lines of pom.
for "non-trivial" (spring-boot-starter), it gets easily into "ten-thousands" (lines of pom).
In intellij we have a "Show effective Pom" command, which basically invokes the mentioned goal and shows the output (in community edition unfortunately!?) without "verbose".
netbeans has a "Effective" tab in its "Pom Editor":
scrolling/cursoring is here also "cumbersome", but we have "full":
"Navigation" (window) support
Text search
Code hints, etc...
(, "Graph" view also very nice...(and unique feature among "maven IDES (that i know)", and it can be installed un-rooted;)!
Update:
So the mojo seems to work as documented:
<verbose> boolean (since:)3.2.0 Output POM input location as comments.
Default value is: false.
User property is: verbose.
For verbose to have an effect, we need to:
<project ...>
...
<build>
<plugins>
<artifactId>maven-help-plugin</artifactId>
<version>3.2.0</version> <!-- or higher! -->
</plugins>
</build>
...
</project>
... respectively can (without pom modification):
mvn -Dverbose=true -Doutput=./eff.pom.xml \
org.apache.maven.plugins:maven-help-plugin:3.2.0:effective-pom
I am trying to update a gradle 6.x version multi project application to gradle 7.3 as it is the first version to support Java 17. However, I am unable to progress past an issue arising from a task which is not declared in any of my build.gradle files. The error is below: ([] pieces are redacted)
Execution failed for task ':[root module]:[module]:processIntTestResources'.
> Entry [filename] is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.3/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
I think is associated with a sourceSet for integration tests, however, I never explicitly copy and files for those tests. I have also set all copy instructions to have this configuration with regard to duplicate handling:
duplicatesStrategy = DuplicatesStrategy.INCLUDE
I also tried adding the above to projects which failed because that setting is only valid for Copy type tasks or blocks. I am by no means an expert in gradle and can add any relevant information needed, but I believe I have included what might be most relevant. I am really just looking for a direction I can head in to further debug this issue.
You didn't show much about how you have integration tests configured, but I ran into a similar problem. What saved me was this blog post by Tom Gregory:
Running integration tests in Gradle
Since links can disappear, let me copy and paste the most important part that I found relevant, which is regarding the new (as of Gradle 7.3) JVM Test Suite Plugin that adds support for integration tests. For me, this replaced my old integration test configuration:
testing {
suites {
integrationTest(JvmTestSuite) {
dependencies {
implementation project
}
}
}
}
tasks.named('check') {
dependsOn testing.suites.integrationTest
}
I also found the following useful, which is not in the above blog post, but is a leftover from my previous Gradle 6 configuration. This for me duplicates the 'test' dependencies for 'integrationTest'. This is not the recommended way of handling the test depedencies now (see the JVM Test Suite Plugin documentation), but I still found it useful to get me back running quickly:
configurations {
integrationTestImplementation.extendsFrom testImplementation
integrationTestRuntime.extendsFrom testRuntime
}
My project is a Gradle dependent JavaFX project using Java JDK 11. The project was made using the default structure of a Gradle project. So under src it has "main" and "test", each consisting of a "java" and a "resource" directory.
For setting up a CI pipeline with Jenkins it is a requirement that gradlew test runs all tests in the same way my IDE (IntelliJ) so far has. The funny thing is, I have not been able to get this to work after hours of trying.
In the IntelliJ run configuration it tests "all in package", within the .test package, and this works just fine (click for screenshot) Below are all the relevant parts of the build.gradle file, please note that I have left out all unrelated parts for simplicity.
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.1.0'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.1.0'
}
test {
useJUnitPlatform()
}
application {
mainClassName = 'FP.EDM.main/edm.Main'
}
Whenever I run the gradlew test command I get the following two errors:
java.lang.RuntimeException: Unable to parse --add-opens <module>/<package>: FP.EDM.main/
Could not write standard input to Gradle Test Executor 1.
java.io.IOException: The pipe is being closed
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at java.base/java.io.FileOutputStream.write(FileOutputStream.java:354)
at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
at org.gradle.process.internal.streams.ExecOutputHandleRunner.forwardContent(ExecOutputHandleRunner.java:67)
at org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:52)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.base/java.lang.Thread.run(Thread.java:834)
Another approach I have tried is to use the useJUnit() command instead of useJUnitPlatform(). At first sight this seems to work perfectly fine however when I use this no tests are found at all. My assumption is that the default module for tests is not set correctly. However I have found no way to set this or no mention of this anywhere online. Please let me know what your thoughts are :)
PS. I would much rather not downgrade to JUnit 4.x since that would require me to rewrite all these (working) tests.
Alright I solved the issue, I'm not quite sure what exactly caused it but it had something to do with the module-info for both the main and test modules. I decided to remove both for the time being and it runs like it should.
Edit:
After days of looking around I got it figured out at last. Adding a module-info.java encapsulates a module and it's dependencies. Because this project applies the gradle-modules-plugin I wouldn't recommend using the same plugin again as it could cause issues though I have not experimented with this myself.
What is the way to go then? Well there are two options:
-Ignore the module-info.java > this can be done in the build.gradle file, for an example of that solution have a look at this
-Specify a module-info.test > this is a way to apply certain dependencies, mine looks like the following:
--add-modules
org.junit.jupiter.api
--add-reads
FP.EDM.main=org.junit.jupiter.api
Please do keep in mind: this file format should go in the root of your source, all my test files were in a different directory in the root, as I didn't get it to work in the root (though that could just be me).
For further reading there is this Git issue which helped me solve it in the first place or this excellent blog by Sormuras which explains a lot
I am trying to use JaCoCo code coverage plugin (3.0.4) in Jenkins (2.138.2). It works as expected, but what I don't like about it is that it does not generate the report when the build is either failed or aborted. This code is here: https://github.com/jenkinsci/jacoco-plugin/blob/master/src/main/java/hudson/plugins/jacoco/JacocoPublisher.java#L585-L587
There is a pull request for this, but looks like it didn't get worked on after its original creation.
So I tried to rebuild the plugin myself with next steps:
Clone https://github.com/jenkinsci/jacoco-plugin
Checkout the latest version 3.0.4
Remove the if statement from above in JacocoPublisher class
Build the plugin (mvn package as they say)
I am able to build it with no problems. The next steps are:
Navigate to Jenkins -> Manage Jenkins -> Manage Plugins -> Advanced
Upload the generated jacoco.hpi file and restart Jenkins
After this is done, the Post Build step to run JaCoCo reports disappears, and I see this in jenkins logs:
06-Nov-2018 17:19:24.353 WARNING [Handling GET /jenkins/job/testing-jacoco-code-coverage-reports/configure from 0:0:0:0:0:0:0:1 : http-nio-8080-exec-3 Job/configure.jelly Project/configure-entries.jelly] hudson.ExpressionFactory2$JexlExpression.evaluate Caught exception evaluating: i.descriptor in /jenkins/job/testing-jacoco-code-coverage-reports/configure. Reason: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
Caused by: java.lang.AssertionError: class hudson.plugins.jacoco.JacocoPublisher is missing its descriptor
at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1517)
at hudson.tasks.Publisher.getDescriptor(Publisher.java:122)
at hudson.tasks.Recorder.getDescriptor(Recorder.java:51)
at hudson.plugins.jacoco.JacocoPublisher.getDescriptor(JacocoPublisher.java:775)
... 168 more
The solution for this issue proposed by Jenkins is not applicable here since the plugin already extends the required classes.
Reverting to previous version (3.0.4 but not of my custom build) makes the build step appear again, but again, is lacking the behavior I need.
Am I missing anything?
Thank you!
After removing the original version, I had to also delete the remaining jacoco plugin files from the /plugins folder. After that, installation went fine.
I can't run vertx module for eclipse project on windows 7
I have followed the instructions here: http://vertx.io/gradle_dev.html
download the template https://github.com/vert-x/vertx-gradle-template
run the tests
cd vertx-gradle-template-master
gradlew.bat test
BUILD SUCCESSFUL
setup the ide
gradlew.bat eclipse
BUILD SUCCESSFUL
trying to run module
gradlew.bat runMod
I got this:
:collectDeps UP-TO-DATE
:runMod
Module directory build\mods\com.mycompany~my-module~1.0.0-final already exists. Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html for information
on the replacement for dynamic properties.
Deprecated dynamic property: "args" on "task ':runMod'", value: "[runmod, com.mycompany...".
Building 50% > :runMod
What I should do with this? I don't understand.
Actually, you got everything working!
The dev guide [0] provides the extra information you need. According to it, Gradle swallows INFO-level messages from the program. If you do it again with '-i', then you will see the missing output that actually indicates things are working as expected.
Here's what I see when I run ./gradlew runmod -i (note that case doesn't matter, this works same as using 'runMod'), where you can see the log message from the PingVerticle class indicating it's waiting for ping messages:
...Same output as from the question...
PingVerticle started
Succeeded in deploying module
> Building 50% > :runMod
Unfortunately, the documentation is sorely lacking and the PingVerticle will just sit there indefinitely until you actually send a ping message yourself.
[0] http://vertx.io/dev_guide.html