Community
Participate
Working Groups
the use case is the if some user tries `./eclipse /path/to/folder` in CLI, they get Eclipse IDE as ready as possible to work with the folder. That can be either by putting selection on this folder (if available as project or as folder under existing project) in the various navigator, or show the Smart Import wizard so user only has to apply to get started with their project in Eclipse IDE.
I'd like to target it for 4.7. I'll try to do it, but since I'm currently working on other topics and don't have time for it right now, I leave it unassigned so anyone interested can feel free to implement that.
Mickael, I have something implemented, but I haven't figured out a way to test it. Reason being, when I run a test child eclipse, I haven't found a way to add the path when running the eclipse application. There's no real other way for me to trigger this method (openFile() in DelayedEventsProcessor) without calling "./eclipse /some/path" as the "open file" menu option only allows actual file selections. Is there some way you know how I can test my build of eclipse like this?
I've never touched that part, so I'm not sure about my answer. However, for the application part, it seems like you could try to send an "SWT.OpenDocument" event to the display once started, with the right parameters for the path, and to get it caught by DelayedEventsProcessor. For the launcher part, I don't know how to properly test it. You should ask this on the mailing-list.
To test, you can try the following to build an IDE locally with your change (success not guaranteed) $ cd ~/git/eclipse.platform.ui $ mvn clean install -Pbuild-individual $ cd ~/git/eclipse.platform/platform/org.eclipse.sdk $ mvn clean verify -Pbuild-individual-bundles Then in the org.eclipse.sdk/target/products folder, you should get the IDE to try. Check it does contain the bundle you're expecting with the right timestamp, and try it.
(In reply to Mickael Istria from comment #4) > $ mvn clean install -Pbuild-individual '-Pbuild-individual-bundles'
One additional item I would like to add for consideration and would be willing to help develop it as well. If no existing .project is found or if the smart-importers can't handle it, we should just generate a .project that is a basic general project so that this folder can be opened in Eclipse. Combine this with the new Generic Text Editor and LSP4E and you have a very similar workflow that is available with editors like sublime and atom.
(In reply to Greg Amerson from comment #6) > If no existing .project is found or if the smart-importers can't handle it, > we should just generate a .project that is a basic general project so that > this folder can be opened in Eclipse. It seems like it's what smart-importer is already doing. Try File > Open Project from Folder... to see it in action.
(In reply to Mickael Istria from comment #7) > (In reply to Greg Amerson from comment #6) > > If no existing .project is found or if the smart-importers can't handle it, > > we should just generate a .project that is a basic general project so that > > this folder can be opened in Eclipse. > > It seems like it's what smart-importer is already doing. Try File > Open > Project from Folder... to see it in action. Would the `eclipse /path/to/folder` always open a wizard? Could it just "do what makes the most sense" automatically?
(In reply to Greg Amerson from comment #8) > Would the `eclipse /path/to/folder` always open a wizard? Could it just "do > what makes the most sense" automatically? The real issue with doing "what makes the most sense" is that for different projects and different users, there is not an obvious answer of what that means, so we cannot automate the resolution of this question at the moment ;) I think we first need to include the change to open the wizard, start gathering feedback on it, and then we may be able to identify some obvious cases when we can skip the wizard. But it's IMO to early to consider this, first is to have `./eclipse /path/to/folder` doing something safe -like showing the wizard-.
Tentative for 4.12. Seems to be a matter of adding a bit of smartness to the DelayedEventProcessor so case of SWT.OpenUrl with URL being an existing local directly would open the SmartImportWizard with directory pre-set.
A process to develop this feature (as typical Debug As > Eclipse application won't work here) 1. Start your usual "dev" IDE from a workspace that has the DelayedEventProcessor class accessible for work in workspace. It's best if the PDE Target Platform is the current running IDE, but other ones may work. 2. Start this same "target" IDE from CLI with the debug arguments: `./eclipse -vmargs -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044 &` and chose whichever workspace that you can discard later 3. From dev IDE, start remote debug the target IDE, monitoring org.eclipse.ui.ide.application project and port 1044 4. From dev IDE, put a breakpoint on `DelayedEventProcessor.openFile(...)` 5. Then from CLI, try `./eclipse /path/to/dir` or `./eclipse .`. Fortunately, the last started instance of the executable (which is the target IDE) seems to be chosen to receive the event, so the breakpoints hits the dev IDE and allows to follow and modify with hot-reload what's happening in the target IDE.
New Gerrit change created: https://git.eclipse.org/r/138366
Gerrit change https://git.eclipse.org/r/138366 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b07379d651c5bba603e1823f2a98d1d4f1e6de98
The import wizard is not showing up for me on Mac (10.13.6). Has anyone tried this on Mac?
(In reply to Lakshmi Shanmugam from comment #14) > The import wizard is not showing up for me on Mac (10.13.6). Has anyone > tried this on Mac? On Mac, this doesn't work with ./eclipse <folder name>. Works with open -a Eclipse.app <folder name>.
