Bug 138335 - Export to directory upon a class file within a library picks up another file for export
Summary: Export to directory upon a class file within a library picks up another file ...
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-25 08:10 EDT by Maxime Daniel CLA
Modified: 2010-03-18 05:57 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Daniel CLA 2006-04-25 08:10:18 EDT
N20060425-0010

Scenario:
- open a Java project;
- deploy the JRE node, then rt.jar, then one of the packages;
- select any of the class files;
- right-click and select export;
- on the first page of the wizard, select File System and click Next;
- you are presented with resources lists within which the current source editor
  file is selected.

I find this quite counter intuitive. If class files of a library cannot be exported, the contextual menu should be disabled when the current selection includes such items. At least, the pre-checked boxes in the wizard should not reflect anything else but what is currently selected in the view. Especially if you consider the case in which the user knowns he selected a single file and doesn't bother reviewing the exported contents.
Comment 1 Martin Aeschlimann CLA 2006-04-26 07:15:53 EDT
The file system export is provided by platform which only knows resources.
I agree with David that when the file exporter cannot hanlde the selected elements, no element should be selected.

The 'Export' menu can't be disabled, how should we know what exporter you choose. 
Comment 2 Karice McIntyre CLA 2006-07-06 14:44:34 EDT
bug 111345 describes the lack of context for import/export in general.
Comment 3 Susan McCourt CLA 2009-07-15 12:13:24 EDT
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
Comment 4 Prakash Rangaraj CLA 2009-07-16 01:51:26 EDT
Project Explorer doesn't show the Import/Export on the JRE/library entries. Its shown only in Package Explorer. Can Package Explorer hide the Export menu on the libraries?
Comment 5 Dani Megert CLA 2009-07-16 02:44:18 EDT
>Project Explorer doesn't show the Import/Export on the JRE/library entries.
That's a bug then. As Martin said: the exporter should simply ignore unknown items. If you have a multi-selection in the Project Explorer you can no longer export and you have to painfully find and unselect those items.
Comment 6 Francis Upton IV CLA 2010-03-08 18:37:16 EST
Dani,

This is the enablement expression in the o.e.ui.navigator.resources plugin.xml for the import/export action provider:

		<actionProvider 
        		id="org.eclipse.ui.navigator.resources.PortingActions"
				class="org.eclipse.ui.internal.navigator.resources.actions.PortingActionProvider">
			<enablement> 
			    <or>
					<adapt type="org.eclipse.core.resources.IResource" />	 
					<adapt type="java.util.Collection"> 
						<count value="0" />
					</adapt>
				</or>	 
			</enablement>
		</actionProvider>


What should it be to make sure that import/export is enabled for the Java objects?
Comment 7 Dani Megert CLA 2010-03-18 05:57:53 EDT
>Project Explorer doesn't show the Import/Export on the JRE/library entries. Its
>shown only in Package Explorer. Can Package Explorer hide the Export menu on
>the libraries?
We don't want to disable the action since import/export always makes sense and we don't have a clue whether someone contributes an import or export wizard for a given element. That's also the reason why the actions in Platform UI are always enabled (and hence File > Import.../Export...) and why the Project Explorer should simply always put those into the context menu (filed bug 306337).

Regarding the initial bug report (which got hijacked a but during the discussion) there's not much we can do about it and hence closing as WONTFIX.