Community
Participate
Working Groups
It is currently possible to open a file from the command line with Eclipse. In Linux that looks like ./eclipse iCore.java It would be extremely desirable to automatically import and open the project in which this file exists if it is actually in a project. If the project is already in the workspace, it should just be opened in the project/package explorer. If a .project file does not exist, it would be ideal to first create the .project file and then import the project similar to the "Import with New Project Wizard" option. We talked about this at length on the Architecture Council list and Mickael Istria suggested that this was the proper place to file the enhancement request. I'm happy to move it if there is a better place. Jay
+1 for this, it would be awesome. > If a .project file does not exist, it would be ideal to first create the > .project file and then import the project similar to the "Import with New > Project Wizard" option. This is a tricky case: finding the root of a project for a given file when there is no .project requires more effort. Just importing current folder as project would end in not very usable workspace. A first iteration could be to simply ask the user to select the root of the project for that file when no .project is found. A second iteration would be to have some mechanism similar to the smart importer which would allow support for project descriptors a-la Maven, NPM, Gulp... to detect the project location looking for additional hints than .project.
It seems simple to change the OpenFileAction to handle that. However, for the command-line I don't know where this is handled. Can someone advise? Also, there's somthing to consider: If one opens a file that has a .project in his hierarchy, would it be ok to pop-up the question "Open project or Open single file?" (with better wording and some explanations) BEFORE actually opening the file? Indeed, if we 1st open file and then import the project in background, then the magic of EditorInput makes that the editor opened against local file won't be associated to file in project, leading to inconsistencies.
(In reply to Mickael Istria from comment #2) > It seems simple to change the OpenFileAction to handle that. However, for > the command-line I don't know where this is handled. Can someone advise? Put a breakpoint in workbenchPage.openEditor() or IDE.openEditor(), they must be hit if you open a file from command line :-) > Also, there's somthing to consider: > If one opens a file that has a .project in his hierarchy, would it be ok to > pop-up the question "Open project or Open single file?" (with better wording > and some explanations) BEFORE actually opening the file? Yes, definitely. > Indeed, if we 1st open file and then import the project in background, then > the magic of EditorInput makes that the editor opened against local file > won't be associated to file in project, leading to inconsistencies. Tricky one. The project might be already in the workspace, and eventually need only to be opened. So depending on what we plan to do, we may ask "Should the enclosing project be [imported|opened]". There can be good reasons why projects are not in the workspace or closed: huge projects, "broken" projects (no dependencies or not compilable etc). So I think a confirmation dialog makes definitely sense, and importing / opening makes sense too.
(In reply to Mickael Istria from comment #2) > It seems simple to change the OpenFileAction to handle that. However, for > the command-line I don't know where this is handled. Can someone advise? It's handled in org.eclipse.ui.internal.ide.application.DelayedEventsProcessor. It may be worth thinking how to generalize this mechanism so a plugin could provide a hook for opening files specific to that plugin, with the Smart Importer providing a default / fallback.
Actually, I don't think this suggestion only applies to startup parameters, but could happen in general for any file opened in the IDE, even someone doing File > Open... should be proposed to import the project if a .project is found in hierarchy.
(In reply to Andrey Loskutov from comment #3) > (In reply to Mickael Istria from comment #2) > > It seems simple to change the OpenFileAction to handle that. However, for > > the command-line I don't know where this is handled. Can someone advise? > > Put a breakpoint in workbenchPage.openEditor() or IDE.openEditor(), they > must be hit if you open a file from command line :-) > Andrey, how abouts are you debugging eclipse so that you are able to set a breakpoint from your Eclipse platform and also debug the child Eclipse that gets started from Command line?
(In reply to Ian Pun from comment #6) > Andrey, how abouts are you debugging eclipse so that you are able to set a > breakpoint from your Eclipse platform and also debug the child Eclipse that > gets started from Command line? The best way is to add the jvm debug parameter to the eclipse.ini of the "child" Eclipse (let's call it AUT for "Application Under Test"), just after -vmargs: -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=1044 I let you refer to more documentation about the possible value of each of the flags. Then you can start you AUT with `eclipse /path/to/whatever` and it should ask for a connection to a debugger. Then, in the development IDE, connect to it as a "Remote Java application" using port 1044. In your dev IDE, you'll be able to set breakpoints and so on. This should help you, hopefully a lot, however it won't help if you have to work on some native parts of the launcher.
(In reply to Mickael Istria from comment #7) > (In reply to Ian Pun from comment #6) > > Andrey, how abouts are you debugging eclipse so that you are able to set a > > breakpoint from your Eclipse platform and also debug the child Eclipse that > > gets started from Command line? > > The best way is to add the jvm debug parameter to the eclipse.ini of the > "child" > Eclipse (let's call it AUT for "Application Under Test"), just after -vmargs: > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=1044 > I let you refer to more documentation about the possible value of each of > the flags. Then you can start you AUT with `eclipse /path/to/whatever` and > it should ask for a connection to a debugger. > Then, in the development IDE, connect to it as a "Remote Java application" > using port 1044. In your dev IDE, you'll be able to set breakpoints and so > on. > This should help you, hopefully a lot, however it won't help if you have to > work on some native parts of the launcher. Yes this is immensely helpful! Thank you
Instead of looking for a .project, such mechanism could use the ProjectConfiguratorExtensionManager introduced in SmartImportWizard to check whether on of the available extensions can import one of the parent folders. Adding a method to the ProjectConfigurator interface may be necessary, something like shouldBeAnEclipseProject(File folder).
For those who are skeptical about this workflow, you can try it in VSCode with the Java extension installed (based on JDTLS): just open a Java file and the language server selects a root by looking up for a .project, a pom.xml or a build.gradle and then configure the "workspace" accordingly to enable (Eclipse's) Java features in VSCode.
As a side note, we have the projects "Go into" action that "hides" the project. I guess this could be very useful for this specific workflow.
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
