Community
Participate
Working Groups
When I run the Oomph setup config for SWT I get. Preparing to commit the provisioning operation. Committing the provisioning operation. Sending ProfileUpdateSucceededEvent[source=Modular Target, profile=C__temp_swt-master2_ws-da7049310bb9aa5ff57170dadde3fdb551f78ec7] to PomArtifactUpdater Sending ProfileUpdateSucceededEvent[source=Modular Target, profile=C__temp_swt-master2_ws-da7049310bb9aa5ff57170dadde3fdb551f78ec7] to PomModulesUpdater Sending ProfileUpdateSucceededEvent[source=Modular Target, profile=C__temp_swt-master2_ws-da7049310bb9aa5ff57170dadde3fdb551f78ec7] to TargetDefinitionGenerator Targlet container profile update completed java.nio.file.ProviderNotFoundException: Provider "jar" not found at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source) at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source) at org.eclipse.jdt.internal.compiler.util.CtSym.init(CtSym.java:137) at org.eclipse.jdt.internal.compiler.util.CtSym.<init>(CtSym.java:120) at org.eclipse.jdt.internal.compiler.util.JRTUtil.lambda$1(JRTUtil.java:136) at java.base/java.util.concurrent.ConcurrentHashMap.compute(Unknown Source) at org.eclipse.jdt.internal.compiler.util.JRTUtil.getCtSym(JRTUtil.java:133) at org.eclipse.jdt.internal.core.builder.ClasspathJrtWithReleaseOption.<init>(ClasspathJrtWithReleaseOption.java:77) at org.eclipse.jdt.internal.core.builder.ClasspathLocation.forJrtSystem(ClasspathLocation.java:146) at org.eclipse.pde.internal.core.TargetPlatformHelper.querySystemPackages(TargetPlatformHelper.java:427) at org.eclipse.pde.internal.core.TargetPlatformHelper.getPlatformProperties(TargetPlatformHelper.java:393) at org.eclipse.pde.internal.core.MinimalState.getProfilePlatformProperties(MinimalState.java:182) at org.eclipse.pde.internal.core.MinimalState.initializePlatformProperties(MinimalState.java:176) at org.eclipse.pde.internal.core.PDEState.<init>(PDEState.java:67) at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:602) at org.eclipse.pde.internal.core.PluginModelManager.targetReloaded(PluginModelManager.java:522) at org.eclipse.pde.core.target.LoadTargetDefinitionJob.resetPlatform(LoadTargetDefinitionJob.java:219) at org.eclipse.pde.core.target.LoadTargetDefinitionJob.runInWorkspace(LoadTargetDefinitionJob.java:146) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:42) at org.eclipse.oomph.util.pde.TargetPlatformUtil.activateTargetDefinition(TargetPlatformUtil.java:156) at org.eclipse.oomph.targlets.internal.core.TargletContainer.forceUpdate(TargletContainer.java:813) at org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl$4.run(TargletTaskImpl.java:1174) at org.eclipse.oomph.util.pde.TargetPlatformUtil.runWithTargetPlatformService(TargetPlatformUtil.java:120) at org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl.perform(TargletTaskImpl.java:1035) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.access$1(SetupTaskPerformer.java:3794) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil$1.run(SetupTaskPerformer.java:5160) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:5154) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.access$0(SetupTaskPerformer.java:5152) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3785) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638) at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:595) at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:722) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Took 717 seconds. There are failed tasks. Press Back to choose different settings or Cancel to abort.
Created attachment 285336 [details] provider not found The comment 0 failure means that I cannot configure target platform as I now get a similar error when looking at preferences -> target platform.
I installed the m2e PDE feature guessing that may have something to do with this, but it made no perceptible difference. There is probably two errors here - one that Oomph's config for SWT has an issue (maybe?) and the other is a PDE bug.
Bug 570516 has the PDE bug.
Created attachment 285338 [details] partial log with full stacktrace for Comment 4 There is another exception in the log which is quite revealing: !SUBENTRY 1 org.eclipse.jdt.core 4 0 2021-01-20 09:30:15.395 !MESSAGE Failed to init ct.sym for C:\Users\msapp\eclipse-installer\plugins\org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.win32.x86_64_15.0.1.v20201027-0507\jre\lib\jrt-fs.jar !STACK 0 java.io.FileNotFoundException: File C:\Users\msapp\eclipse-installer\plugins\org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.win32.x86_64_15.0.1.v20201027-0507\jre\lib\ct.sym does not exist at org.eclipse.jdt.internal.compiler.util.CtSym.init(CtSym.java:126)
Probably duplicate of bug 569513.
*** Bug 570516 has been marked as a duplicate of this bug. ***
Yes, please try updating your installer. Also just exiting and starting the IDE from scratch should fix the problem too, i.e, I think there is no -vm option in your eclipse.ini. *** This bug has been marked as a duplicate of bug 569513 ***
Restarting did solve the problem. However the problem still exists in 1.19.0 Build 4919 (the installer's update is disabled and I had just downloaded it today, so I guess this is up to date?). I can see the command line the installer used to launch the just created eclipse is: C:\temp\committers-latest\eclipse\eclipse.exe -vmargs -Duser.dir=C:\temp\committers-latest\eclipse So no explicit -vm used from installer, and the eclipse.ini also does not have -vm. But the installer/launcher or JVM (presumably?) has changed the PATH to add its own JVM at the front of the path: Path C:/Users/msapp/eclipse-installer//plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.win32.x86_64_15.0.1.v20201027-0507/jre/bin/server;C:/Users/msapp/eclipse-installer//plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.win32.x86_64_15.0.1.v20201027-0507/jre/bin;C:\Program Files\AdoptOpenJDK\jdk-11.0.9.101-hotspot\bin; -- snip -- Looking at the fix in Bug 569513 it looks like only the case where JAVA_HOME is set will the -vm arg be added. Therefore I am respectfully reopening this. Bug 570512 Attachment 285333 [details] shows what my JVMs are, and I will add I have no JAVA_HOME set.
Note that I did not say restart. I said exit and start from scratch. Please confirm there is no -vm line in your eclipse.ini. I say it that way because the problem is exactly that the native launcher mangles the PATH environment and without an explicit -vm argument for the actual process launch from the installer process, the one on the installer environment's PATH is found and includes the JRE of the installer. And I believe a restart will reuse the environment PATH that is was launched with when launched from the installer.
(In reply to Ed Merks from comment #9) > Note that I did not say restart. I said exit and start from scratch. Yes indeed. I did close and start again, which did work around the problem. But the problem just recurs the next time I run the installer and for the next user, hence the extra diagnosis I provided. I can try to provide the fix, but I don't know oomph well enough. In the case I ran into I guess oomph has decided that I am using default vm and not added -vm to eclipse.ini. Is the heuristic the same when it gets to launching the new eclipse instance? Because I don't have JAVA_HOME set, I assume not. > > Please confirm there is no -vm line in your eclipse.ini. > There is none.
You must update the installer to have one with the fix! Or you can download a new one from here: https://download.eclipse.org/justj/?file=oomph/products The fix was to pass a -vm argument to the process launch when the eclipse.ini does not have a -vm argument in it: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/diff/plugins/org.eclipse.oomph.setup.ui/src/org/eclipse/oomph/setup/ui/wizards/ProgressPage.java?id=dda7c66e6fb4be55da622c3c91a2f1f12cbaf93d
Created attachment 285346 [details] uptodate (In reply to Jonah Graham from comment #8) > However the problem still exists in 1.19.0 Build 4919 (the installer's > update is disabled and I had just downloaded it today, so I guess this is up > to date?). I did make sure I was up to date according to the installer (see screenshot) but the version in your download link is newer anyway. Something else missing so that installer knows it is out of date? It normally does.
I've had that before that my installer stopped finding updates. It seems that's the case again so I could try to remote debug an older installer again; it seemed to me last time it was related to some issue of needing to remove some feature in order to do an update. In any case, the latest version should be 1.20.0 and it should not have this problem, which has been confirmed by someone other than me...
When I updated to the newer installer it started putting the -vm in the eclipse.ini - so something else changed in the meantime. As for the not updating the installer, I would respectfully say that if you are asking people to update to a newer installer, including the version number may save you some time. I did ask in Comment 8 and as the installer itself was showing up to date I assumed I was done. I can't really help diagnose much more, so I have returned the duplicate designation. Thanks for your time. *** This bug has been marked as a duplicate of bug 569513 ***
