I build my xtext eclipse plugin project with maven and jenkins and the junit tests with tycho surefire. Jenkins runs on a 64 bit ubuntu and tests are failing with:
java.lang.IllegalStateException: Unresolved proxy http://url/from/mydsl#//element. Make sure the EPackage has been registered.
I tried to solve this problem with an overidden register function in the StandaloneSetup class like described at Switching from an inferred Ecore model to an imported one in your Xtext grammar but this didn't work for me.
I tried to run the tests on ubuntu 32 bit and it surprisingly works without failure.
I hope somebody can help me
Related
is there any reason for a jacoco coverage report to produce different results when running it in a CI environment?
I have the following situation after migrating to Java 17. when I run ./gradlew clean build the report is generated and the jacocoTestCoverageVerification doesnt fail.
But when the same command is executed in a github runner I have a very different result, the coverage report is also created with different coverage values and some classes just fail the coverage verification.
Unfortunately, I cannot provide code snippets but I already tried this:
Run the github runner on my machine, with the same jdk and it produces a different result if I just run the build in the command line :(
add jvmargs noverify for tests tasks
run the github action in a container instead of a self-hosted, same result
other devs have also built the project on different machines without error
run the same build command of the ci
So it seems that something in a github action env produces this behavior.
versions:
jacoco plugin: 0.8.7
gradle 7.3
java 17
The problem here was lombok config files. It turns out that the new version of lombok plugin compatible with java 17 and Gradle 7.3 does not generate the lombok.config files anymore.
In the previous version, these files were generated by io.freefair.lombok plugin, and we had them in .gitignore. Because of that, a local build worked just fine, since the files were still there.
I realized this by looking at the generated reports and I noticed that lombok classes were being analyzed only by the CI.
In other cases, a similar problem could be related to this:
https://www.eclemma.org/jacoco/trunk/doc/classids.html
Could someone please suggest me the required Intellij Idea setup to run a junit test refers to lombok annotations with Java 1.6.
My current setup:-
Intellij Version - 2020.3.3 with built-in lombok plugin
lombok dependency version - 1.16.18
My previous question on the issue:-
lombok annotations are not identified by junit in Intellij
I can build the project with maven but cannot run unit test with Intellij. When I changed to Java 8 and try to run unit tests, lombok error disappeared, but failed since project is not compatible with Java 8.
Therefore I'm looking for the ideal Intellij setup that works for this situation.
Thanks in advance!
I'm hitting a weird issue were my unit tests fail when running mvn install but they pass when running in IntelliJ.
I've looked at posts online about debugging maven, but I don't want to debug maven itself, or a maven plugin. I want to debug my unit tests when they have been called by maven. More specifically, I want to debug my code but using the Junit tests as an entry point for the debugging via a breakpoint.
Hope that makes sense.
My issue is relating to using introspection to look at some classes the application is importing from another project. This succeeds when the project is running or running in debug mode, but fails when maven runs the tests as a part of an install. i.e. the code doesn't find the classes in the other project when running under maven...
As this application uses multiple maven projects that all need to be installed, I've had to move my unit tests out into another project just so that the installs don't fail and I can carry on development.
However, for obvious reasons I would like to put my unit tests in each individual project, so am very keen to debug this and find out what is failing.
My project is called infinite-state-machine and can be found here - https://github.com/museadmin/infinite-state-machine
The unit tests are currently in their own project here - https://github.com/museadmin/infinite-state-machine-test
If anyone can advise me how to run maven in debug mode and attach IntelliJ to it so that I can set a breakpoint in my failing unit tests I will be forever in their debt :)
Thanks in advance for any help.
Brad
I started using Hudson a week ago. I was able to add various plugins to my build cycle (like ci-game, email-ext and Sonar) but i am unable to get the svn-tag to work.
I am using the latest version of the Hudson war (2.2.0) and the version 1.16 of the Subversion Tagging Plugin.
When a build fails test the plugin tells me that it didn't do anything (since the build failed) but, when the build runs fine the plugin tells me nothing.
Checking http://myserver/hudson/log/all i can see the following stacktrace:
SEVERE: Executor threw an exception
java.lang.NoSuchMethodError: hudson.model.AbstractBuild.getRootBuild()Lhudson/model/AbstractBuild;
at hudson.plugins.svn_tag.SvnTagPlugin.perform(SvnTagPlugin.java:79)
at hudson.plugins.svn_tag.SvnTagPublisher.perform(SvnTagPublisher.java:79)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:630)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:608)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.cleanUp(MavenModuleSetBuild.java:835)
at hudson.model.Run.run(Run.java:1409)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:414)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Does anyone know how to fix this ? Am i missing something ?
Thanks in advance!
It looks like there's a difference between hudson CI and jenkins CI. Jenkins provides the method hudson.model.AbstractBuild.getRootBuild() while, according to the java doc, it is not part of hudson.
JavaDoc for AbstractBuild at jenkins
JavaDoc for AbstractBuild at hudson
The plugin may not be compatible with oracle hudson CI.
I have a Maven-managed project that uses Mockito mocking in its unit tests. I can run all the tests within a Maven build, and they run without error (and pass!). However, if I right-click a single test function, and choose "Run As -> JUnit Test", I get an exception java.lang.NoSuchMethodError: org.mockito.Mockito.doAnswer(Lorg/mockito/stubbing/Answer;)Lorg/mockito/stubbing/Stubber;. Of course, the "missing" method is there if I look at the sources, and like I said the tests compile and run from the command line.
Best I can think of is if Eclipse is trying to "help" me by providing an outdated Mockito artifact (I'm using 1.8.5 in my Maven dependencies) for the JUnit plugin, akin to how the Maven plugin can stick you with an oddball version of the Maven runtime for certain tasks.
Is this the problem? Is it something else? Can I fix this?
ETA: Apparently this may relate to a known issue. There's a good chance that it stems from having multiple versions of Mockito in my classpath (thanks, Maven :-/ ). I seem to have my house in order -- Eclipse can run the tests now -- but unfortunately the bug has bitten my Hudson. I have to track down how to remove the old JAR from the classpath there as well.
Make sure the unit-test classpath has the correct mockito. You can check this from the run dialog. Btw, Eclipse does not ship with mockito, so perhaps you are having two versions of it. Take a look at your maven dependency graph and search for duplicates.
I had the similar problem and I found that I had both "mockito-all 1.8.x" and "mockito-core 1.9.5" in my classpath. I was supposed to use only 1.9 but somehow eclipse was putting 1.8 before 1.9.5 in the classpath. I removed 1.8.x and it worked ;)