Community
Participate
Working Groups
Build ID: I20080617-2000 On right-clicking a project in package explorer -> Export -> Runnable Jar File the Launch configuration should be restricted to the launch configurations in the selected project and the Export destination should default to the project directory of the selected project. The Jar-Name should default to the Launch Configuration Name.
>the Launch configuration should be restricted to the launch configurations in >the selected project Sounds nice on first thought but the problem is that people might want to export but currently have a different project selected. They would then be confused not find the other launch configs and would have to quit the wizard, find the project in which they have (or think they have) the config and start over again. We could do this if the wizard has a project selection area so that the filtered launch configs could be changed. Suggest to close as WONTFIX. Ferenc, what do you think about this? > and the Export destination should default to the project >directory of the selected project. No, as normally people don't export stuff into the workspace.
* the Launch configuration should be restricted to the launch configurations in the selected project * the Export destination should default to the project directory * The Jar-Name should default to the Launch Configuration Name. That is a lot of automated logic which is not always wanted. The Runnable Jar File Export wizard stores the last setting in the workspace (independend of the project) and has some history for the input fields. I think this is standard behaviour for export wizards. Are there any wizards which behave different when opened via the context menue? Best regards, feri
>Are there any wizards which behave different when opened via the context menue? Most of them are initialized based on the current selection (no matter whether opened from context or main menu or key binding). The difference is that those wizards then allow to change the initial values/selections.
We could preselect a launch-config from the currently selected project and leave the list of Launch-configs complete. So the preselection can be overwritten with Launch-Configs from other projects. The filename could be renamed according to the project-name (or Launch-Config-name) and the path is kept unchanged from the last stored settings. I am not too happy about this weak automatism. Perhpas there should be project-specific settings. Preselecting a project overwrites the stored settings (with workspace-scope) with the last stored project-specific settings. But this might also lead to confusion. What about adding an option to save the wizard-settings to a file (like jardesc) and right-clicking this file and selecting "Export..." restores the stored settings?
Saving to a file is another feature. I think it's a valid point to pre-fill the wizard (the normal JAR Exporter and all new wizards do this). So, I see two options: 1) add a field for the project like we have in the new source folder wizard for example and then pre-fill that field and fill in the launch configs for the project. The user can then either clear the project field or choose a new project. 2) WONTFIX
Adding a project selection which filters the Launch-Configurations will be quirky, because in most cases each project will have only one Launch-Configuration. So preselecting a project is nearly equivalent to preselecting the first Launch-Configuration of the project. Looking at the JAR-Exporter: The files to be packaged are preselected by the project, the filename is for all projects the same. Suggestion: Preselecting the first Launch-Config of the selected project might be a simple solution which is consistent with the JAR-Exporter behaviour.
Well, I have several projects with more than one launch config. You might also have more than one for the same app but with slightly different parameters. Please choose 1) or 2) from comment 5 ;-)
2) WONTFIX
* Selecting the context menu of an object means doing something with exactly that object. So, selecting the Export wizard in the context menu of a project certainly should not select run configurations of another project * File export should show all projects * if a project has more than one Run Configuration there should be a drop down For WONTFIX I will continue my usual workflow for the Jar Exporter: ;-) Start Exporter Where's my project on the file system? (might be in the workspace or deep in a Clearcase snapshot) Cancel Exporter and close Open Project Properties Copy file system path into clipboard Start Exporter again paste file path Scroll down the list of about 30 or 40 Run Configurations and select the right one
> Selecting the context menu of an object means > doing something with exactly that object. > So, selecting the Export wizard in the context > menu of a project certainly should not select > run configurations of another project The point is: The Export Wizard does not know whether it was started via the context-menue or via file-export menu. So if the user has accidentaly selected a project in the Package-Explorer and select "File > Export" the Wizard will also show only the Launch-Configs of the select project. > Scroll down the list of about 30 or 40 Run > Configurations and select the right one Ok, for too many run-configs the dialog is not very usable. I will think again about Daniels Law #5.1) "add an Project input field which can be preselected by the current selection" ;)
> The point is: The Export Wizard does not know whether it was started via the > context-menue or via file-export menu. This design issue should be fixed. A wizard should now on what it is working. Why does the Project->Delete wizard know then on what it is working? And it better should.
>The point is: The Export Wizard does not know whether it was started via the >context-menue or via file-export menu. Even if it does: we never make that difference. The only difference is that some main menu actions don't appear in the context menu if no appropriate or important enough. >This design issue should be fixed. A wizard should now on what it is working. Be our guest ;-) OK, lets keep this open as low prio.
Created attachment 112805 [details] patch for org.eclipse.jdt.ui, add project-field in Dialog Added project-field with browse-button in wizard-dialog. If exactly one (Java)Project is selected it overwrites the stored value from the last export. Only Launch-Configurations for the current Launch-Config are shown. Refactored the status handling.
(In reply to comment #13) > Only Launch-Configurations for the current Launch-Config are shown. oops, should be: Only Launch-Configurations for the selected project are shown.
Hi Ferenc, I don't like the new UI. Besides that it doesn't seem to be initialized by the selected project it doesn't allow to select more than one project. If we attack this bug then we should have two lists aside each other where all Java projects are on the left and the launch configurations of the selected projects on the right. Opening the wizard would select the projects that are currently selected in the active view (e.g. Package Explorer) and would fill all their launch configs on the right side. The label provider on the right side would only append the project name if more than project is selected on the left.
Hello Daniel, I see no advantage in having multiple Projects selected concurrently in the wizard. I have looked at the New-Source-Folder-Wizard and tried to realize the same behaviour. The New-Source-Folder-Wizard also has only one Project-Input field with an Browse-Button. It is initialized if exactly one project is selected, otherwise the project-field is empty. [Nearby: The Finish Button of the New-Source-Folder-Wizard is initialized wrong (enabled) when the project-field is initially empty] I think showing more than one project will confuse the user. To select a project and then refine the selection by selecting a launch-configuration is straight forward and easy to understand. > it doesn't seem to be initialized by the selected project The preselection for the project inputfield only works if the project itself is selected in the Package-Explorer. It does not work for sub-selections like a package, Java-Class, ... I could fix this. > I don't like the new UI. The layout for the project input field is different from the others - stolen from the new-src-wizard :-) I could change the layout so that the label is above the input field and not on the left side.
>I see no advantage in having multiple Projects selected concurrently in the >wizard. >I have looked at the New-Source-Folder-Wizard and tried to realize the same >behaviour. This scenario is different as the wizard should help to select 1 launch configuration out of all your projects. Imagine the Package Explorer is in working set mode: if I select a working set and then want to export, I'd expect to see all launch configs from that working set being shown (and if there's exactly one launch config, then that config should also be selected). The JDT UI component leads (Markus and I) have discussed this and we'd only accept a solution that works toward comment 15.
I think this is a bug really. If i want to export a runnable jar i get tons of "Launch configurations" (about 130) from different projects and can't find the right one, because: 1. Even launch configurations from *closed* projects are shown (why should anyone want to work on a project without opening it?) 2. The launch configurations are not ordered in any way (neither project nor class name) This is really not in any way desirable - only chaos. The named two points could be changed without "a lot of automated logic": - restrict to opened projects - order by project and class name (or at least class name)
(In reply to Andi Gonneck from comment #18) > I think this is a bug really. If i want to export a runnable jar i get tons > of "Launch configurations" (about 130) from different projects and can't > find the right one, because: > > 1. Even launch configurations from *closed* projects are shown > (why should anyone want to work on a project without opening it?) See bug 541570. > The named two points could be changed without "a lot of automated logic": Any help is welcome.
