Community
Participate
Working Groups
Created attachment 270960 [details] Sample project - Import attached project having JUnit 5 container on modulepath and its module-info.java is having "requires org.junit.jupiter.api;". - Open pp.T1.java and Run As > JUnit Test. We get the exception: java.lang.NoClassDefFoundError: org/junit/platform/launcher/core/LauncherFactory at org.eclipse.jdt.internal.junit5.runner.JUnit5TestLoader.<init>(JUnit5TestLoader.java:31) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488) at java.base/java.lang.Class.newInstance(Class.java:558) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.createRawTestLoader(RemoteTestRunner.java:368) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.createLoader(RemoteTestRunner.java:363) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.defaultInit(RemoteTestRunner.java:307) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.init(RemoteTestRunner.java:222) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206) Caused by: java.lang.ClassNotFoundException: org.junit.platform.launcher.core.LauncherFactory at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) ... 11 more
I remember testing this scenario earlier with an M-build and it was working fine. This doesn't allow any JUnit test to be run in a Java 9 project having module-info.java.
It works in M20170921-0255 but fails in M20170925-0650.
Reverting http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?h=R4_7_maintenance&id=888c4faa6ce043b4d5bbf8e2415dfa9c68491935 from bug 522333 comment #24 fixes this issue. Sarika, please have a look.
SO link for this issue: https://stackoverflow.com/questions/46717693/eclipse-no-tests-found-using-junit-5-caused-by-noclassdeffounderror.
It will be good to fix it for 4.8 M3 so that it can be backported to 4.7.2 after proper testing. I will upload a patch for master branch using the new #getClasspathAndModulepath API instead of the old #getClasspath API in JUnitLaunchConfigurationDelegate.
https://git.eclipse.org/r/#/c/110276/ This updates the code in JUnitLaunchConfigurationDelegate based on the given instructions. It works for a JDK 8 project and JDK 9 project not having module-info.java. For JDK 9 project having module-info.java (comment #0), it now gives the following error instead of the one in comment #0: Error: Could not find or load main class org.eclipse.jdt.internal.junit.runner.RemoteTestRunner Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.junit.runner.RemoteTestRunner Sarika, can you please check if the patch is doing what's expected?
(In reply to Noopur Gupta from comment #6) > https://git.eclipse.org/r/#/c/110276/ > > This updates the code in JUnitLaunchConfigurationDelegate based on the given > instructions. > > It works for a JDK 8 project and JDK 9 project not having module-info.java. > > For JDK 9 project having module-info.java (comment #0), it now gives the > following error instead of the one in comment #0: > > Error: Could not find or load main class > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner > Caused by: java.lang.ClassNotFoundException: > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner > > > Sarika, can you please check if the patch is doing what's expected? Missing part in launch method - IJavaProject proj = JavaRuntime.getJavaProject(configuration); if (proj != null) { IModuleDescription module = proj == null ? null : proj.getModuleDescription(); String modName = module == null ? null : module.getElementName(); if (modName != null) { runConfig.setModuleDescription(modName); } } VMRunnerConfiguration is checked while running to see if -m option is to be added or not.
New Gerrit change created: https://git.eclipse.org/r/110296
(In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/110296 I am now setting the project's module description name in VMRunnerConfiguration. With this, the exception changes to: Error occurred during initialization of boot layer java.lang.module.FindException: Unable to derive module descriptor for C:\Eclipse\Builds\eclipse-SDK-I20171011-2000\eclipse\plugins\org.junit.jupiter.migrationsupport_5.0.0.v20170910-2246.jar Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.junit.jupiter.engine.JupiterTestEngine not in module The JUnit 5 container having these JARs is present on the project's modulepath and these JAR are also returned in the modulepath via super.getClasspathAndModulepath(configuration) API call. So, these should have been handled as automatic modules here. The above exception on console does not have any further stack trace as well. Sarika, what's missing? :)
Problem is in the name - org.hamcrest.core_1.3.0.v201303031735.jar This name is not suitable for automodule jar and that's what is being complained by Java 9. And adding Junit library to Classpath in Buildpath gives compilation error.
(In reply to Sarika Sinha from comment #10) > Problem is in the name - org.hamcrest.core_1.3.0.v201303031735.jar > > This name is not suitable for automodule jar and that's what is being > complained by Java 9. All the JARs in Eclipse's plugins folder are of this form so all of them will have this issue when added to modulepath. Also, the JUnit 5 JARs have Automatic-Module-Name set in their MANIFEST.MF so the module name should be picked from there (but the exception mentions problems with jupiter.engine and jupiter.migrationsupport JARs). And JDT Core also creates valid names for auto modules. Not sure if those names can be used here. > And adding Junit library to Classpath in Buildpath gives compilation error. This should be allowed unless the user wants to explicitly put the JUnit JARs on modulepath to be included in the project's module-info.java file. Adding JDT Core members to comment on these points.
(In reply to Noopur Gupta from comment #11) > (In reply to Sarika Sinha from comment #10) > > Problem is in the name - org.hamcrest.core_1.3.0.v201303031735.jar > > > > This name is not suitable for automodule jar and that's what is being > > complained by Java 9. > > All the JARs in Eclipse's plugins folder are of this form so all of them > will have this issue when added to modulepath. Looks like this issue is being worked on in PDE for 4.7.2. > Also, the JUnit 5 JARs have Automatic-Module-Name set in their MANIFEST.MF > so the module name should be picked from there (but the exception mentions > problems with jupiter.engine and jupiter.migrationsupport JARs). The exception with JUnit 5 JARs having Automatic-Module-Name is: (from comment #9) > Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > C:\Eclipse\Builds\eclipse-SDK-I20171011-2000\eclipse\plugins\org.junit.jupiter.migrationsupport_5.0.0.v20170910-2246.jar > > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class > org.junit.jupiter.engine.JupiterTestEngine not in module This happens because jupiter.migrationsupport JAR registers JupiterTestEngine as a service but it is not present in the same JAR. I removed the JUnit 5 container from test project's modulepath and added the JUnit 5 JARs individually to the modulepath (I did not add the old junit.jar and org.hamcrest.core_1.3.0.v201303031735.jar) and I tried the following options: - Moved jupiter.migrationsupport JAR to the end in the build path order tab. Running the test still gave the above exception. - Removed the jupiter.migrationsupport JAR from the modulpath. Now, the error in the Console view is: Error: Could not find or load main class org.eclipse.jdt.internal.junit.runner.RemoteTestRunner in module p9WithModuleInfo I get the same error when I try to run a JUnit 4 test with junit.jar and org.hamcrest.core.jar (without the qualifier) in a Java 9 project with module-info.java. Sarika, can you please have a look? The InvalidModuleDescriptorException for provider class org.junit.jupiter.engine.JupiterTestEngine not in module org.junit.jupiter.migrationsupport should be discussed with the JUnit team.
I am not able to see any thing wrong in the command line. From launching point of you, only thing for temporary fix can be done is to remove the check in getClasspath() so that all modulepath entries are part of classpath which makes it work.
(In reply to Sarika Sinha from comment #13) > From launching point of you, only thing for temporary fix can be done is to > remove the check in getClasspath() so that all modulepath entries are part > of classpath which makes it work. Will that work when the new getClasspathAndModulepath() API is used instead of the old getClasspath() API as done in the attached patch? Otherwise, let me know the changes required for the usage of the new API so that the patch can be updated accordingly with this debug change. I don't think we should revert back to using the old API on the client.
(In reply to Noopur Gupta from comment #14) > (In reply to Sarika Sinha from comment #13) > > From launching point of you, only thing for temporary fix can be done is to > > remove the check in getClasspath() so that all modulepath entries are part > > of classpath which makes it work. > > Will that work when the new getClasspathAndModulepath() API is used instead > of the old getClasspath() API as done in the attached patch? Otherwise, let > me know the changes required for the usage of the new API so that the patch > can be updated accordingly with this debug change. I don't think we should > revert back to using the old API on the client. I am talking about only old API now, as with new API and module path the jars and module names are not getting resolved.
(In reply to Sarika Sinha from comment #15) > (In reply to Noopur Gupta from comment #14) > > (In reply to Sarika Sinha from comment #13) > > > From launching point of you, only thing for temporary fix can be done is to > > > remove the check in getClasspath() so that all modulepath entries are part > > > of classpath which makes it work. > > > > Will that work when the new getClasspathAndModulepath() API is used instead > > of the old getClasspath() API as done in the attached patch? Otherwise, let > > me know the changes required for the usage of the new API so that the patch > > can be updated accordingly with this debug change. I don't think we should > > revert back to using the old API on the client. > > I am talking about only old API now, as with new API and module path the > jars and module names are not getting resolved. OK, this will be a temporary fix as you already mentioned. It can probably be released for 4.7.2, that's up to you. We should keep this bug open to find the proper fix in master and then backport it to R4_7_maintenance.
(In reply to Noopur Gupta from comment #11) > (In reply to Sarika Sinha from comment #10) > > And adding Junit library to Classpath in Buildpath gives compilation error. > > This should be allowed unless the user wants to explicitly put the JUnit > JARs on modulepath to be included in the project's module-info.java file. Reported bug 526937 for this.
> The InvalidModuleDescriptorException for provider class org.junit.jupiter.engine.JupiterTestEngine not in module That's a definite bug. Oops! I'll fix that in JUnit 5 immediately and report back here.
The aforementioned bug regarding accidental registration of the JupiterTestEngine within the migration support module has been fixed in `master` for JUnit 5. https://github.com/junit-team/junit5/issues/1148 This fix will be released in 5.0.2, which will likely be released within the next week. Regards, Sam
Thanks, Sam. It will be picked up when updated JUnit 5 JARs are provided in Eclipse Orbit. With this, we are now left with the following issue in Eclipse launching when used with the attached Gerrit patch: (In reply to Noopur Gupta from comment #12) > Error: Could not find or load main class > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner in module > p9WithModuleInfo RemoteTestRunner is not present in the module project, but it is present in the org.eclipse.jdt.junit.runtime bundle which is now being added to the project's modulepath via the new debug API in the attached patch. (In reply to Noopur Gupta from comment #16) > (In reply to Sarika Sinha from comment #15) > > I am talking about only old API now, as with new API and module path the > > jars and module names are not getting resolved. > > OK, this will be a temporary fix as you already mentioned. It can probably > be released for 4.7.2, that's up to you. We should keep this bug open to > find the proper fix in master and then backport it to R4_7_maintenance. Sarika, please let us know how to proceed here.
(In reply to Noopur Gupta from comment #20) > (In reply to Noopur Gupta from comment #12) > > Error: Could not find or load main class > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner in module > > p9WithModuleInfo > > RemoteTestRunner is not present in the module project, but it is present in > the org.eclipse.jdt.junit.runtime bundle which is now being added to the > project's modulepath via the new debug API in the attached patch. > Does it run outside of Eclipse with this structure, meaning does it run the class which is not in the main module and is in the modular path?
You can also try with passing org.eclipse.jdt.junit.runtime bundle auto module name in the argument with -m. Currently -m provides the argument of the current module name and there it can not find the launching class.
(In reply to Sarika Sinha from comment #21) > (In reply to Noopur Gupta from comment #20) > > > (In reply to Noopur Gupta from comment #12) > > > Error: Could not find or load main class > > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner in module > > > p9WithModuleInfo > > > > RemoteTestRunner is not present in the module project, but it is present in > > the org.eclipse.jdt.junit.runtime bundle which is now being added to the > > project's modulepath via the new debug API in the attached patch. > > > Does it run outside of Eclipse with this structure, meaning does it run the > class which is not in the main module and is in the modular path? How to check that? Are there any users/test cases of the new API that add a main class to the modulepath? In Eclipse, it used to run when the main class was on classpath. Now, adding it either to classpath or modulepath doesn't run. (In reply to Sarika Sinha from comment #22) > You can also try with passing org.eclipse.jdt.junit.runtime bundle auto > module name in the argument with -m. > > Currently -m provides the argument of the current module name and there it > can not find the launching class. Not sure if that can/should be done. We don't have access to the auto module name of junit.runtime bundle and ideally it should find the main class from the modulepath of the current project, like it used to do with the classpath.
Previously you could run a java class from default package, now you can't do that with Java 9 modular project. So it's not about only API here. First thing is -m <moduleName> will not work here as here the module name is the modular project which has test class. It might be Automodule name and class to be launched. But we need to test outside Eclipse that does it work with Auto modules and -m combination?
(In reply to Sarika Sinha from comment #24) > But we need to test outside Eclipse that does it work with Auto modules and > -m combination? Any steps or command line args to try that?
Also, just noticed that the API #getClasspath and its usage cannot be simply replaced with #getClasspathAndModulepath in JUnitLaunchConfigurationDelegate as clients of JUnitLaunchConfigurationDelegate may be overriding/using that. And a change in super.getClasspath(..) will have an effect on them as well. It would be helpful to get a usage/migration guide describing the changes.
JEP says - http://openjdk.java.net/jeps/261 At run time it is the application's main module, as specified via the --module (or -m for short) launcher option. -m <modulename>/<fully classified class to launch> Yes we need to have a migration guide. We can create it after we have successfully migrated one :)
Moving to 4.7.3 as it needs more analysis and testing.
(In reply to Sarika Sinha from bug 526502 comment #29) > Even if it is not test resources, maven will continue to put everything in > classpath and nothing in modulepath for Java 9 going forward or it is till > Java 8 behavior ? That is the current behaviour. They are working on extending surefire to put things on the module-path: https://issues.apache.org/jira/browse/SUREFIRE-1262 and there are two branches for that (i think the second one is the relevant one): https://github.com/apache/maven-surefire/tree/SUREFIRE-1262 https://github.com/apache/maven-surefire/tree/SUREFIRE-1262_2 Should we assume this is fixed and only support what will be done then?
(In reply to Till Brychcy from comment #29) > (In reply to Sarika Sinha from bug 526502 comment #29) > > Even if it is not test resources, maven will continue to put everything in > > classpath and nothing in modulepath for Java 9 going forward or it is till > > Java 8 behavior ? > > That is the current behaviour. > > They are working on extending surefire to put things on the module-path: > > https://issues.apache.org/jira/browse/SUREFIRE-1262 > and there are two branches for that (i think the second one is the relevant > one): > https://github.com/apache/maven-surefire/tree/SUREFIRE-1262 > https://github.com/apache/maven-surefire/tree/SUREFIRE-1262_2 > > Should we assume this is fixed and only support what will be done then? Looks like they'll be using the same mixture of module-path+class path as for compilation: Main code and all dependencies required in module-info.java will be on the module path, all other dependencies go to the class-path (including e.g. junit + their launching code) and then there will be --patch-module statements for the local test code and --add-reads and --add-exports statements involving ALL-UNNAMED
I've created bug 527593 for supporting launching with multiple output folders.(In reply to Till Brychcy from comment #30) > Looks like they'll be using the same mixture of module-path+class path as > for compilation: Main code and all dependencies required in module-info.java > will be on the module path, all other dependencies go to the class-path > (including e.g. junit + their launching code) and then there will be > --patch-module statements for the local test code and --add-reads and > --add-exports statements involving ALL-UNNAMED Bug 520713 Comment 25 has an example how maven compiles and will launch tests. I think we should also implement that approach (leave the test-runner on the classpath and add --add-exports module=ALL-UNNAMED) Also, it would be good to fix Bug 527593 first, before tests are launched as modules.
(In reply to Till Brychcy from comment #31) > > I think we should also implement that approach (leave the test-runner on the > classpath and add --add-exports module=ALL-UNNAMED) > The main problem which we need to fix first is that Junit launcher launches the org.eclipse.jdt.internal.junit.runner.RemoteTestRunner class which is not defined in a module. Without that how can we support module path during launching?
(In reply to Sarika Sinha from comment #32) > (In reply to Till Brychcy from comment #31) > > > > > I think we should also implement that approach (leave the test-runner on the > > classpath and add --add-exports module=ALL-UNNAMED) > > > > The main problem which we need to fix first is that Junit launcher launches > the org.eclipse.jdt.internal.junit.runner.RemoteTestRunner class which is > not defined in a module. Without that how can we support module path during > launching? Classes on the classpath live in the unnamed module. The unnamed module can access classes in modules on the module-path (the Java 9 JDK classes are modules on the module-path!), so the class containing the "main" method can be on the classpath and it can still access modules. To make the modules accesiable to the unnamed module, we just need to add --add-modules and --add-exports, like in the example from Bug 520713 Comment 25 (which can be actually executed with the code from Bug 520713 Comment 0): java --module-path target/classes --class-path junit-4.8.2.jar --add-modules m --patch-module m=target/test-classes --add-reads m=ALL-UNNAMED --add-exports m/p1=ALL-UNNAMED org.junit.runner.JUnitCore p1.P1Test Thinking about it, in Junit5, test methods don't have to be public, so we may have to use --add-opens instead of --add-exports. (The --add-reads m=ALL-UNNAMED is only necessary if the junit-classes are on the classpath; if junit was on the module path and required in the module-info.java, this could be skipped)
Noopur, Can we put org.eclipse.jdt.internal.junit.runner in classpath and try out what Till suggested?
So, we tried putting the junit jar and the project in the module path and the junit eclipse jars in the classpath and launching the eclipse junit Runner class like - javaw.exe --add-modules=ALL-SYSTEM -p TestJUnitJava9\bin;junit.jar -classpath org.eclipse.jdt.junit4.runtime\bin;org.eclipse.jdt.junit.runtime\bin org.eclipse.jdt.internal.junit.runner.RemoteTestRunner -classNames p.T4 But we still get the error implying that junit.jar is not available - java.lang.NoClassDefFoundError: org/junit/runner/manipulation/Filter at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:292) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadTestLoaderClass(RemoteTestRunner.java:377) Till, any suggestions to proceed?
(In reply to Noopur Gupta from comment #35) > So, we tried putting the junit jar and the project in the module path and > the junit eclipse jars in the classpath and launching the eclipse junit > Runner class like - > > javaw.exe > --add-modules=ALL-SYSTEM > -p TestJUnitJava9\bin;junit.jar > -classpath > org.eclipse.jdt.junit4.runtime\bin;org.eclipse.jdt.junit.runtime\bin > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner > -classNames p.T4 > > But we still get the error implying that junit.jar is not available - > java.lang.NoClassDefFoundError: org/junit/runner/manipulation/Filter > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:292) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > loadTestLoaderClass(RemoteTestRunner.java:377) > > Till, any suggestions to proceed? If you put junit.jar on the modulepath, it is treated as (automatic) module, so you need to add --add-modules=junit to make the code in it visible to code in the unnamed module (== code on the classpath).
Thanks Till, we tried and it worked but after we added the test module also as --add-modules, not sure why is that required as that is a module defined and not an auto module ?
(In reply to Sarika Sinha from comment #37) > Thanks Till, we tried and it worked but after we added the test module also > as --add-modules, not sure why is that required as that is a module defined > and not an auto module ? It must be reachable from the "root set", but isn't unless you add it with --add-modules. (If you run a java modular application with java --module xyz/a.b.c.Main, xyz will be added to the root set.) Maybe for running tests it would work to just use --add-modules=ALL-MODULE-PATH References: https://docs.oracle.com/javase/9/docs/api/java/lang/module/package-summary.html http://openjdk.java.net/jeps/261
(In reply to Till Brychcy from comment #38) > Maybe for running tests it would work to just use > --add-modules=ALL-MODULE-PATH Thanks, Till. This worked. (In reply to Till Brychcy from comment #33) > java --module-path target/classes --class-path junit-4.8.2.jar --add-modules > m --patch-module m=target/test-classes --add-reads m=ALL-UNNAMED > --add-exports m/p1=ALL-UNNAMED org.junit.runner.JUnitCore p1.P1Test > > Thinking about it, in Junit5, test methods don't have to be public, so we > may have to use --add-opens instead of --add-exports. Adding "--add-opens m/p1=ALL-UNNAMED" doesn't work but "--add-opens m/p1=org.junit.platform.commons" seems to work for JUnit 5 tests. I will update the JDT UI patch to add the above VM arguments and Sarika will upload the JDT Debug patch with any required changes.
(In reply to Noopur Gupta from comment #39) > Adding "--add-opens m/p1=ALL-UNNAMED" doesn't work but "--add-opens > m/p1=org.junit.platform.commons" seems to work for JUnit 5 tests. This is matter of where you put the junit jar(s): If on the classpath (maven-style), --add-opens m/p1=ALL-UNNAMED is needed, if on the modulepath, the option you wrote. Maybe we can ignore where it is and just add both options. (BTW: I wonder if --add-opens m/p1=ALL-MODULE-PATH would work?)
New Gerrit change created: https://git.eclipse.org/r/113373
Gerrit change https://git.eclipse.org/r/113373 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=88456d603141293e34227689020b309fa0b8e312
(In reply to Till Brychcy from comment #40) > (In reply to Noopur Gupta from comment #39) > > Adding "--add-opens m/p1=ALL-UNNAMED" doesn't work but "--add-opens > > m/p1=org.junit.platform.commons" seems to work for JUnit 5 tests. > > This is matter of where you put the junit jar(s): If on the classpath > (maven-style), --add-opens m/p1=ALL-UNNAMED is needed, if on the modulepath, > the option you wrote. > Maybe we can ignore where it is and just add both options. Yes, I am adding both now. > (BTW: I wonder if --add-opens m/p1=ALL-MODULE-PATH would work?) It doesn't work.
New Gerrit change created: https://git.eclipse.org/r/113400
I have updated the JDT UI patch with required changes. Till, please have a look if you like. (In reply to Eclipse Genie from comment #44) > New Gerrit change created: https://git.eclipse.org/r/113400 Uploaded PDE patch to deprecate the old #getClasspath API and use the new #getClasspathAndModulepath API. TODO: - Get updated JUnit 5 JARS in Orbit having the fix from comment #19. - Check how to update the org.hamcrest.core JAR in Orbit so that it has the Automatic-Module-Name set in its MANIFEST.MF.
Gerrit change https://git.eclipse.org/r/110296 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=c99742a3330f064ed7a20dc9d74f5d94c153b2ae
Gerrit change https://git.eclipse.org/r/113400 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=c1ce4a94bd449da1a52124c0acde761f63bb59f5
https://git.eclipse.org/r/#/c/113405/ increased the bundle version (Genie did not update this bug, see bug 528782). That was wrong as no new API got added, just overriding an inherited API. Reverted with http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=eba2aa3b161d84404210e2d7093d288848a9a135
(In reply to Dani Megert from comment #48) > https://git.eclipse.org/r/#/c/113405/ increased the bundle version (Genie > did not update this bug, see bug 528782). That was wrong as no new API got > added, just overriding an inherited API. > > Reverted with > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=eba2aa3b161d84404210e2d7093d288848a9a135 > See bug 528790.
(In reply to Noopur Gupta from comment #45) > TODO: > - Get updated JUnit 5 JARS in Orbit having the fix from comment #19. > - Check how to update the org.hamcrest.core JAR in Orbit so that it has the > Automatic-Module-Name set in its MANIFEST.MF. Created bug 529120 for the TODOs.
New Gerrit change created: https://git.eclipse.org/r/114632
New Gerrit change created: https://git.eclipse.org/r/114633
New Gerrit change created: https://git.eclipse.org/r/114634
Gerrit change https://git.eclipse.org/r/114633 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=3a84deb22ba8ef62d8b8f83b9efb4a869f8325a2
Gerrit change https://git.eclipse.org/r/114634 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=4a964520231f54e8cde052b45c810fc4bd8c2379
Gerrit change https://git.eclipse.org/r/114632 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=86df74bd56c41e93520eb6dff1d7d49539390ad3
(In reply to Eclipse Genie from comment #54) > Gerrit change https://git.eclipse.org/r/114633 was merged to > [R4_7_maintenance]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > ?id=3a84deb22ba8ef62d8b8f83b9efb4a869f8325a2 Updated jdt.launching bundle version http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?h=R4_7_maintenance&id=0a0efc36ac6bec9d00a2c8247237a8a063dfeb32
Merged all the changes for 4.7.3 and verified the fix in a runtime workbench. To be verified in 4.7.3 build.
Verified for 4.7.3 in M20180207-1700.
Hello, how come I still have this bug in 4.7.3a ? java.lang.ClassNotFoundException: org.junit.platform.launcher.core.LauncherFactory
(In reply to pH Cito from comment #60) > Hello, how come I still have this bug in 4.7.3a ? > java.lang.ClassNotFoundException: > org.junit.platform.launcher.core.LauncherFactory This bug was fixed and verified in 4.7.3. If you still see the issue, please open a new bug with steps to reproduce.
