Sunbelt Computer Software

Comment 1 Noopur Gupta 2017-10-12 13:03:18 EDT

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.

Comment 2 Noopur Gupta 2017-10-12 13:08:49 EDT

It works in M20170921-0255 but fails in M20170925-0650.

Comment 3 Noopur Gupta 2017-10-12 13:30:47 EDT

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.

Comment 4 Noopur Gupta 2017-10-13 10:33:02 EDT

SO link for this issue: https://stackoverflow.com/questions/46717693/eclipse-no-tests-found-using-junit-5-caused-by-noclassdeffounderror.

Comment 5 Noopur Gupta 2017-10-18 03:45:54 EDT

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.

Comment 6 Noopur Gupta 2017-10-18 04:43:13 EDT

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?

Comment 7 Sarika Sinha 2017-10-18 05:41:55 EDT

(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.

Comment 8 Eclipse Genie 2017-10-18 06:10:01 EDT

New Gerrit change created: https://git.eclipse.org/r/110296

Comment 9 Noopur Gupta 2017-10-18 06:33:09 EDT

(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? :)

Comment 10 Sarika Sinha 2017-10-18 13:54:31 EDT

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.

Comment 11 Noopur Gupta 2017-10-18 14:27:49 EDT

(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.

Comment 12 Noopur Gupta 2017-10-25 16:00:48 EDT

(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.

Comment 13 Sarika Sinha 2017-10-30 07:16:28 EDT

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.

Comment 14 Noopur Gupta 2017-10-30 07:46:13 EDT

(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.

Comment 15 Sarika Sinha 2017-10-30 12:25:38 EDT

(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.

Comment 16 Noopur Gupta 2017-10-31 08:37:33 EDT

(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.

Comment 17 Noopur Gupta 2017-11-07 09:08:58 EST

(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.

Comment 18 Sam Brannen 2017-11-07 11:12:11 EST

> 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.

Comment 19 Sam Brannen 2017-11-07 11:25:12 EST

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

Comment 20 Noopur Gupta 2017-11-07 12:02:00 EST

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.

Comment 21 Sarika Sinha 2017-11-07 23:55:09 EST

(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?

Comment 22 Sarika Sinha 2017-11-07 23:58:27 EST

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.

Comment 23 Noopur Gupta 2017-11-08 00:26:46 EST

(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.

Comment 24 Sarika Sinha 2017-11-08 00:48:30 EST

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?

Comment 25 Noopur Gupta 2017-11-08 01:00:54 EST

(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?

Comment 26 Noopur Gupta 2017-11-08 01:08:28 EST

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.

Comment 27 Sarika Sinha 2017-11-08 01:13:21 EST

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 :)

Comment 28 Sarika Sinha 2017-11-08 04:37:48 EST

Moving to 4.7.3 as it needs more analysis and testing.

Comment 29 Till Brychcy 2017-11-16 04:14:21 EST

(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?

Comment 30 Till Brychcy 2017-11-16 06:34:07 EST

(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

Comment 31 Till Brychcy 2017-11-22 03:03:58 EST

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.

Comment 32 Sarika Sinha 2017-11-23 23:29:40 EST

(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?

Comment 33 Till Brychcy 2017-11-24 02:53:11 EST

(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)

Comment 34 Sarika Sinha 2017-11-24 04:02:08 EST

Noopur, 
 Can we put org.eclipse.jdt.internal.junit.runner in classpath and try out what Till suggested?

Comment 35 Noopur Gupta 2017-12-11 05:20:36 EST

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?

Comment 36 Till Brychcy 2017-12-11 16:47:12 EST

(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).

Comment 37 Sarika Sinha 2017-12-12 06:17:55 EST

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 ?

Comment 38 Till Brychcy 2017-12-13 02:25:36 EST

(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

Comment 39 Noopur Gupta 2017-12-13 09:40:35 EST

(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.

Comment 40 Till Brychcy 2017-12-13 10:07:04 EST

(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?)

Comment 41 Eclipse Genie 2017-12-14 00:03:03 EST

New Gerrit change created: https://git.eclipse.org/r/113373

Comment 42 Eclipse Genie 2017-12-14 04:46:15 EST

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

Comment 43 Noopur Gupta 2017-12-14 05:10:30 EST

(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.

Comment 44 Eclipse Genie 2017-12-14 05:11:38 EST

New Gerrit change created: https://git.eclipse.org/r/113400

Comment 45 Noopur Gupta 2017-12-14 05:27:26 EST

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.

Comment 46 Eclipse Genie 2017-12-14 06:02:32 EST

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

Comment 47 Eclipse Genie 2017-12-14 06:02:46 EST

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

Comment 48 Dani Megert 2017-12-14 09:24:53 EST

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

Comment 49 Noopur Gupta 2017-12-14 11:30:02 EST

(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.

Comment 50 Noopur Gupta 2017-12-22 02:02:40 EST

(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.

Comment 51 Eclipse Genie 2017-12-22 02:06:28 EST

New Gerrit change created: https://git.eclipse.org/r/114632

Comment 52 Eclipse Genie 2017-12-22 02:06:31 EST

New Gerrit change created: https://git.eclipse.org/r/114633

Comment 53 Eclipse Genie 2017-12-22 02:21:45 EST

New Gerrit change created: https://git.eclipse.org/r/114634

Comment 54 Eclipse Genie 2017-12-22 06:06:57 EST

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

Comment 55 Eclipse Genie 2017-12-22 06:10:12 EST

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

Comment 56 Eclipse Genie 2017-12-22 06:10:35 EST

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

Comment 57 Sarika Sinha 2017-12-22 06:22:27 EST

(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

Comment 58 Noopur Gupta 2017-12-22 06:28:52 EST

Merged all the changes for 4.7.3 and verified the fix in a runtime workbench. To be verified in 4.7.3 build.

Comment 59 Noopur Gupta 2018-02-08 07:33:01 EST

Verified for 4.7.3 in M20180207-1700.

Comment 60 Nobody - feel free to take it 2018-11-13 06:07:16 EST

Hello, how come I still have this bug in 4.7.3a ?
java.lang.ClassNotFoundException: org.junit.platform.launcher.core.LauncherFactory

Comment 61 Noopur Gupta 2018-11-13 06:35:01 EST

(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.