Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 191722

Summary:	[Import/Export] File system export wizard required compatibility layer
Product:	[Eclipse Project] Platform	Reporter:	Matthew Dickie <m.dickie>
Component:	UI	Assignee:	Tod Creasey <Tod_Creasey>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	dak2009
Version:	3.3	Keywords:	helpwanted
Target Milestone:	3.4
Hardware:	All
OS:	All
Whiteboard:

Description Matthew Dickie

2007-06-08 11:17:46 EDT

Build ID: I20070601-1539

Steps To Reproduce:
1. Create an Eclipse product that doesn't require the compatiability layer.
2. Launch the product
3. Create a project
4. Try to open the File System Export Wizard.
An error dialog will appear reporting that the class org.eclipse.ui.wizards.datatransfer.FileSystemExportWizard could not be created.


More information:
The error appears because the constructor for FileSystemExportWizard uses API that is deprecated and that only works with the compatiability layer (plugin org.eclipse.core.runtime.compatiability). The problem is with the first line of the constructor (line 68): Plugin.getBundle(): an IllegalStateException is thrown from Platform.getBundle() (line 732). This problem means that anyone wanting to make these wizards available to users of the product need to add the compatiability layer, even though their own code is fully Eclipse 3.0. Also, the problem is a little tricky to spot and track down. 

ZipFileExportWizard has exactly the same problem.

Comment 1 David Kyle

2007-07-11 10:20:44 EDT

I see the same problem with build I20070621-1340. Our application uses org.eclipse.ui.ide which appears to have lost its dependency upon org.eclipse.runtime.compatibility. When the ResourceNaviagator view is show it fails to create due to the same IllegalStateException described above.

Comment 2 Tod Creasey

2007-10-11 16:52:12 EDT

We should remove that reference all together as it is crossing plug-in boundaries for no good reason.

We should change the WorkbenchWizardNode subclasses to do something like NewWizardAction does where it looks up the workbench dialog settings and applies them (see NewWizardAction #run)

Comment 3 Tod Creasey

2008-01-30 09:56:17 EST


*** This bug has been marked as a duplicate of bug 209558 ***