Community
Participate
Working Groups
The plugins org.eclipse.files.ui and org.eclipse.shells.ui have a hard dependency to org.eclipse.debug.core. This is problematic for minimal (RCP) installations which should be able to run without debug.core installed. The dependency to org.eclipse.debug.core is only needed in order to perform source lookups which are configured through an associated project: in other words, as long as the API call IRemoteCommandShell.associateProject(IProject) is never called, the corresponding code can never be executed. Moreover, the code actually doing the source lookups is duplicated in three places: * SystemEditProjectFileLineAction * SystemRemoteFileLineOpenWithMenu * SystemViewRemoteOutputAdapter It would be better to introduce a new interface e.g. IRemoteSourceLookupProvider, which has an implementation being declared in an additional plugin especially dedicated to debugging (e.g. org.eclipse.rse.debug). Then, * only the additional plugin (org.eclipse.rse.debug) would need to have the dependencies into org.eclipse.debug.core; it would be possible to provide a "minimal" RSE without debugging facilities. * A different default implementation of IRemoteSourceLookupProvider could be provided in rse.core, just parsing workspace resource names and doing a default lookup (but without using any facilities from debug.core). * the duplicated code for executing the source lookup could be kept in only one place in the rse.debug plugin * We would most probably need an additional API IRemoteCommandShell.associateSourceLookup(IRemoteSourceLookupProvider) For users of the existing functionality, migration would be rather easy: wherever they used to do IRemoteCommandShell.associateProject(proj); they would now need to do IRemoteCommandShell.associateProject(proj); IRemoteCommandShell.associateSourceLookup(new RSEDebugSourceLookup(proj)); Please comment on this proposal. -----------Enter bugs above this line----------- RSE 1.0 Release Test installation : eclipse-SDK-3.2.1 RSE install : update-site RSE 1.0 complete java.runtime : Sun 1.5.0_08-b03 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : Windows-local, Dstore-win, Dstore-linux targetos : Red Hat Enterprise Linux WS release 4 (Nahant Update 3) targetuname : Linux parser 2.6.9-34.EL #1 i686 athlon i386 GNU/Linux targetvm : Sun Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) ------------------------------------------------
This is now fixed. The dependency existed due to obsolete code that had been used to associate a local project resource (not temp files) with a remote error or file. The debug source lookup mechanism had been used for that purpose however that approach is no longer in use.
So when I get you right, the user-visible impact of this change is this: When doing a command like "gcc -c myFile.c" in a Remote Shell, and the command produces some error output, selecting the line and choosing Open With > Editor will now ALWAYS navigate to the remote file. Before that change, it was possible to associate a local project with the remote shell, and configure a debug source lookup that would allow navigating to the local workspace resource instead. But, since associating the project was only possible programmatically in openRSE, the users would not see any change. Correct?
Right. This stuff was once exposed to the user via RSE external tools and RSE external build. A local project could be associated with the shell that was used to run a build command and the remote file for an error could be mapped back to a file in the local project via a source lookup in that project. Given that EFS seems to be the way things will go for remote project-oriented stuff, this approach would probably be the wrong way to go if/when we brought RSE external tools into open source. It probably makes sense to get rid of the associateProject() api as well.
Hmm... I'm not sure EFS is the only solution for remote build. In my opinion, a *local* workspace that gets synchronized to the remote side (through an RSE export operation, rsync or similar) before building remotely is more effective because it is much better suited for local tooling (static analysis, parsers, config management etc) -- at least in some scenarios, the remote side will be used for build only. [There may be others where static analysis, CM etc. are done remotely.] Therefore, adding back some sort of source lookup for remote errors might be interesting in the future. But if that is done, it should be done in a manner that avoids dependencies on debug in the core (and injects a source lookup mechanism from a separate plugin).
Actually, I do agree about the usefulness of a local "replica" project that is associated with one or more remote targets. I've been involved in several discussions about this in the past and I do see it's value over the 1-to-1 mapping that an EFS project would be limited to. Regarding source lookup, though, I imagine that there would be a more optimal way of associating build errors with the associated replica project resource.
Amen :-)
