Community
Participate
Working Groups
Using `eclipse <path/to/file>` (which actually uses the --launcher.openFile feature) * eclipse file => ✔️ Works, opens file * eclipse relative/path/to/file => ✔️ Works, opens file * eclipse /absolute/path/to/file => ✔️ Works, opens file Now with line number * eclipse /absolute/path/to/file:10 => ✔️ Works, opens file at line 10 * eclipse file:10 => 😞 Does not work, nothing happens * eclipse relative/path/to/file:10 => 😞 Does not work, popup saying file doesn't exist is shown.
Some findings: For the case of "file:10" (direct child of current directory), the event is sent as OpenURL and not as OpenDocument. The reason is simple: "file:10" is a valid URL. The case of relative files in general is a bit trickier: the DelayedEventProcessor doesn't get the resolved path but just the raw parameter; and the current user.dir of the running Eclipse IDE may differ from the one used when running the `eclipse path/to/file` command. As a result, the relative path in the context of the command may not resolve to an actual file in the context of the running IDE. Both problems could have a same solution: the OpenURL or OpenDocument event should either pass a resolved path (so some parsing and more file resolution has to happen in launcher as it does when no `:` is part of the path), or they should also contain the user.dir of the command, so the DelayedEventProcessor would resolve it.