Bug 49008 - Target workspace doesn't start anymore
Summary: Target workspace doesn't start anymore
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Update (deprecated - use Eclipse>Equinox>p2) (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P1 blocker (vote)
Target Milestone: 3.0 M6   Edit
Assignee: Dorian Birsan CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 48632 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-17 09:20 EST by Dirk Baeumer CLA
Modified: 2019-07-11 07:24 EDT (History)
7 users (show)

See Also:


Attachments
The launch config I am using to start the target workspace (67.90 KB, image/gif)
2003-12-17 11:10 EST, Dirk Baeumer CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2003-12-17 09:20:27 EST
M6 test candidate

Tried to launch my target workspace after importing binary plugins and get the 
following in the log:

!SESSION ----------------------------------------------------------------------
!ENTRY org.eclipse.core.launcher 4 0 Dec 17, 2003 15:18:07.83
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.NullPointerException
	at java.lang.Throwable.<init>(Throwable.java:59)
	at java.lang.Throwable.<init>(Throwable.java:73)
	at java.lang.NullPointerException.<init>(NullPointerException.java:60)
	at org.eclipse.core.internal.boot.FeatureEntry.getFeatureVersion
(FeatureEntry.java:28)
	at org.eclipse.ui.internal.WorkbenchPlugin.initializeProductInfo
(WorkbenchPlugin.java:597)
	at org.eclipse.ui.internal.WorkbenchPlugin.getAppName
(WorkbenchPlugin.java:627)
	at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:258)
	at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.IDEApplication.run
(IDEApplication.java:41)
	at org.eclipse.core.internal.runtime.PlatformActivator$1.run
(PlatformActivator.java:233)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:85)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:79)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:41)
	at java.lang.reflect.Method.invoke(Method.java:386)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:281)
	at org.eclipse.core.launcher.Main.run(Main.java:744)
	at org.eclipse.core.launcher.Main.main(Main.java:583)
Comment 1 Kai-Uwe Maetzel CLA 2003-12-17 09:26:32 EST
I have the same problem. The point is that our launch configs only enable plug-
ins in the workspace. The workspace does not contain any feature. Raising to 
blocker.
Comment 2 Jeff McAffer CLA 2003-12-17 10:58:08 EST
Need more exact steps.  I can import plugins as binary and run the target.  I 
can even open the About dialog and inspect the platform feature.
Comment 3 Dirk Baeumer CLA 2003-12-17 11:07:54 EST
I have the following workspace layout:

org.eclipse.core.resources.win32
org.eclipse.swt.win32
org.eclipse.update.core.win32
org.apache.ant
org.apache.lucene
org.eclipse.ant.core
org.eclipse.compare
org.eclipse.core.boot
org.eclipse.core.filebuffers  <=== source
org.eclipse.core.resources
org.eclipse.core.runtime
org.eclipse.core.runtime.compatibility
org.eclipse.core.variables
org.eclipse.debug.core
org.eclipse.debug.ui
org.eclipse.help
org.eclipse.help.appserver
org.eclipse.help.base
org.eclipse.jdt.core  <=== source
org.eclipse.jdt.debug
org.eclipse.jdt.debug.ui
org.eclipse.jdt.launching
org.eclipse.jdt.ui  <=== source
org.eclipse.jdt.ui.examples.javafamily  <=== source
org.eclipse.jdt.ui.examples.projects  <=== source
org.eclipse.jdt.ui.tests  <=== source
org.eclipse.jdt.ui.tests.refactoring  <=== source
org.eclipse.jface
org.eclipse.jface.text  <=== source
org.eclipse.osgi
org.eclipse.osgi.services
org.eclipse.osgi.util
org.eclipse.search
org.eclipse.search.core  <=== source from ottcvs1 repository
org.eclipse.search.ui  <=== source from ottcvs1 repository
org.eclipse.swt
org.eclipse.team.core
org.eclipse.text  <=== source
org.eclipse.ui
org.eclipse.ui.console
org.eclipse.ui.editors  <=== source
org.eclipse.ui.ide
org.eclipse.ui.views
org.eclipse.ui.win32
org.eclipse.ui.workbench
org.eclipse.ui.workbench.texteditor  <=== source
org.eclipse.update.configurator
org.eclipse.update.core
org.junit

I will attach a screen shot showing the launch configuration I use.
Comment 4 Dirk Baeumer CLA 2003-12-17 11:10:26 EST
Created attachment 7212 [details]
The launch config I am using to start the target workspace
Comment 5 Dirk Baeumer CLA 2003-12-17 11:20:17 EST
Trying the same with a fresh workspace and the following plug-ins as binary

org.eclipse.core.resources.win32
org.eclipse.swt.win32
org.eclipse.ui.workbench.compatibility
org.eclipse.update.core.win32
org.apache.ant
org.eclipse.ant.core
org.eclipse.compare
org.eclipse.core.filebuffers
org.eclipse.core.resources
org.eclipse.core.runtime
org.eclipse.core.runtime.compatibility
org.eclipse.core.variables
org.eclipse.debug.core
org.eclipse.debug.ui
org.eclipse.help
org.eclipse.jdt.core
org.eclipse.jdt.debug
org.eclipse.jdt.launching
org.eclipse.jdt.ui
org.eclipse.jface
org.eclipse.jface.text
org.eclipse.osgi
org.eclipse.osgi.util
org.eclipse.search
org.eclipse.swt
org.eclipse.team.core
org.eclipse.text
org.eclipse.ui
org.eclipse.ui.console
org.eclipse.ui.editors
org.eclipse.ui.ide
org.eclipse.ui.views
org.eclipse.ui.win32
org.eclipse.ui.workbench
org.eclipse.ui.workbench.texteditor
org.eclipse.update.configurator
org.eclipse.update.core
org.eclipse.osgi.services

results in the following exception and a canceled launch

!ENTRY org.eclipse.pde.core 4 4 Dec 17, 2003 17:16:45.854
!MESSAGE Exception caught while creating platform configuration.
!STACK 0
java.lang.NullPointerException
	at 
org.eclipse.pde.internal.core.DefaultRuntimeSupport.getPluginLocation
(DefaultRuntimeSupport.java:39)
	at org.eclipse.pde.internal.core.TargetPlatform.getPluginLocation
(TargetPlatform.java:356)
	at 
org.eclipse.pde.internal.core.TargetPlatform.createConfigurationEntries
(TargetPlatform.java:345)
	at 
org.eclipse.pde.internal.core.TargetPlatform.savePlatformConfiguration
(TargetPlatform.java:275)
	at 
org.eclipse.pde.internal.core.TargetPlatform.createPlatformConfigurationArea
(TargetPlatform.java:174)
	at 
org.eclipse.pde.internal.ui.launcher.WorkbenchLaunchConfigurationDelegate.getPr
ogramArguments(WorkbenchLaunchConfigurationDelegate.java:138)
	at 
org.eclipse.pde.internal.ui.launcher.WorkbenchLaunchConfigurationDelegate.creat
eVMRunner(WorkbenchLaunchConfigurationDelegate.java:86)
	at 
org.eclipse.pde.internal.ui.launcher.WorkbenchLaunchConfigurationDelegate.launc
h(WorkbenchLaunchConfigurationDelegate.java:47)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch
(LaunchConfiguration.java:156)
	at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch
(DebugUIPlugin.java:740)
	at org.eclipse.debug.ui.DebugUITools.buildAndLaunch
(DebugUITools.java:625)
	at org.eclipse.debug.ui.DebugUITools$3.run(DebugUITools.java:581)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:62)
Comment 6 DJ Houghton CLA 2003-12-17 11:21:11 EST
Dirk, I got the same problem as you (fresh workspace case) and have entered bug
49035.
Comment 7 John Arthorne CLA 2003-12-17 11:52:57 EST
I have reproduced this in my workspace. 

I deleted the org.eclipse.platform project from my workspace yesterday because
it was failing to start a test workspace.  I do not have org.eclipse.platform
selected in the list of external plugins in my target platform setup.

So, this problem can be reproduced by trying to start a test workspace with
absolutely no feature plugins in the configuration.  When I added
org.eclipse.platform to my workspace, it started fine.

In essence this is user error because I had an invalid configuration, but it
should have failed more gracefully than a NullPointerException.
Comment 8 Wassim Melhem CLA 2003-12-17 11:56:20 EST
To clarify: 
When launching a runtime workbench, we do not pass any features.  So if you 
have 0 or 10 features in your workspace, it makes no differene.

Jeff, note that the Zurich folks are launching without the primary plugin 
org.eclipse.platform, and that is what is causing the problem.  You are 
assuming its presence.

I don't think org.eclipse.platform is mandatory to start.  Only the plugins in 
the config.ini are essential.  One should never assume the presence of any 
other plugins.
Comment 9 Wassim Melhem CLA 2003-12-17 12:10:31 EST
Re comment #7, it is not a user error to not have org.eclipse.platform.

The core runtime only cares about plugins.  It does not care about features or 
which plugin is the primary plugin.  Only the Update component does.
  
When we launch a runtime workbench, we make sure that the Update reconciling 
is bypassed.  This is because we pass the -configuration fileURL argument, 
with a file containing exactly the list of plugins that need to run.
Comment 10 Jeff McAffer CLA 2003-12-17 12:36:11 EST
The runtime does not assume anything about org.eclipse.platform.  The only 
thing needed is the locatoin of the startup code.  It seems that the 
configuration code is somehow expecting to have a feature entry and there isn't 
one because org.eclipse.platform is missing.

The only other issue I can think of is the code which accesses the feature 
entries may be expecting to get back null if there are none.  With the 
compatibility support, we may be wrappering that null rather than returning it.
Comment 11 John Arthorne CLA 2003-12-17 17:47:33 EST
It looks like this bug has been around for awhile.  See Jeem's comments in bug
48632.  I will close that one as a duplicate since most of the discussion is in
here.
Comment 12 John Arthorne CLA 2003-12-17 17:47:49 EST
*** Bug 48632 has been marked as a duplicate of this bug. ***
Comment 13 Jeff McAffer CLA 2003-12-17 18:15:56 EST
Raising priority to see if we can get it in for this week.  

Wassim, can you comment on a path forward here.  Is it a wrapper error, 
configuration error, ...
Comment 14 Wassim Melhem CLA 2003-12-17 18:40:08 EST
I think it's best if PlatformConfiguration.getPrimaryFeatureId() returned null 
if it contains no features.  Currently, it returns the 
default "org.eclipse.platform" if no features, which is causing all this 
confusion.

Since features are not required by the core runtime, and self-hosting using a 
pde-crafted config file is a good example of that, then it's perfectly ok for 
a primary feature id to return null;

A quick check on who calls this method, it seems that Platform UI code does 
check if the getPrimaryFeatureId() returns null.  However, classes 
BaseHelpSystem (i.e. Help team) and OperationsValidator (i.e. Update team) do 
not.  So these two teams have to modify their code to check for null.
Comment 15 Wassim Melhem CLA 2003-12-17 18:55:23 EST
dorian, you would be interested in comment #14
Comment 16 DJ Houghton CLA 2003-12-17 19:07:00 EST
This sounds good to me. (especially since the spec of IPlatformConfiguration
says that it can return null)

Moving to PDE/UI for closure. (and co-ordination with Help/Update to handle the
use cases illustrated above)
Comment 17 Dorian Birsan CLA 2003-12-17 19:24:10 EST
I will change 
org.eclipse.update.internal.configurator.PlatformConfiguration.getPrimaryFeatur
eIdentifier() return null if the feature is not configured and will fix the 
calls from Help and Update.
The implementation will return null if findConfiguredFeatureEntry(featureId) 
return null.

I assume this is an M6 candidate fix, right ?
Comment 18 Dorian Birsan CLA 2003-12-17 20:16:10 EST
Moving to Update to fix as suggested.
Comment 19 Dorian Birsan CLA 2003-12-17 20:18:57 EST
Fixed and released for the next (12 am) build.
I'd suggest all the teams cc:ed on this bug do a quick sanity test on this 
build.
Comment 20 Jeff McAffer CLA 2003-12-17 22:38:48 EST
Thanks to all for pulling together on this.  I have a further question.  Does 
it make sense for the old configuration objects to wrapper new objects which 
are actually null?  The fix that was put in resolved one case but I wonder if 
there are others?  Confidence level?
Comment 21 Eclipse Genie CLA 2019-07-11 07:16:48 EDT
New Gerrit change created: https://git.eclipse.org/r/145921
Comment 22 Ed Merks CLA 2019-07-11 07:24:01 EDT
Sorry, I committed to Gerrit with a wrong Bugzilla number.