Community
Participate
Working Groups
Created attachment 169543 [details] Angelo's proposed this solution for enabling remote launching with the existing DLTK infrastructure Hi! I have added Angelo to this Bug since he restarted the discussions. I have also added Lionel since he mentioned that IBM might also be interested in this in the future. ------------------- The discussion is rather old but now since it's making waves it's high time we started this issue. DLTK framework, which is currently providing the launch infrastructure for XQDT, has a major limitation: remote launching/running of XQuery. This is the case of MarkLogic adapter plugins. Angelo came up with a solution from the X-Hive Project. (See Attachment: "Angelo's solution.htm" or http://dev.eclipse.org/mhonarc/lists/wtp-incubator-dev/msg01203.html).
Removed at posters request by Webmaster
My response to Angelo's e-mail was: --------------------------------------------- Hi Angelo, Thanks your your e-mail. I have looked over the proposed solution and the solution works but I think there is a cleaner solution (although a little more complex) to integrate your RunnableProcess into the IInterpreterRunner. This solution I try to explain below: 1. DLTK has the notion of "execution environments" (org.eclipse.dltk.core.environment.IExecutionEnvironment). Both MarkLogic and your use case are not suitable for a LocalExecEnvironment for a series of reasons raging from UI to Lunching and Debug functionality. Therefore this brings again the need of a "RemoteExecEnvironment" which is unfortunately not available in DLTK (at least DLTK 1.0, but it's worth to search for it in DLTK 2.0). This will solve the java.lang.Process problem in an elegant manner. But you have to come up with the RemoteExecEnvironment code. This implies that that an IEnvironment also needs to be coded, probably RemoteEnvironment, just like org.eclipse.dltk.core.internal.environment.LocalEnvironment. To define a new environment, you must use the "org.eclipse.dltk.core.environment" extension point. 2. DebugPlugin.newProcess can be extended with the help of the "org.eclipse.debug.core.processFactories" extension point. In this way you can define your own IProcess. Look how we did it in the Sausalito plugins (org.eclipse.wst.xquery.set.launching/plugin.xml) These two points seem to integrate well with the DLTK infrastructure, at least from what I see in theory. Thus you can have your own RunnableProcess passed to your own RuntimeProcess. IMHO I think that the AbstractInterpreterRunner is generic enough and need no more extensions for this problem. Regards, Gabriel PS: I was usually against DLTK (because I use it). But it's not that bad afterall
Added people to this bug.
The content of attachment 169543 [details] has been deleted by Eclipse Webmaster <webmaster@eclipse.org> who provided the following reason: Poster request The token used to delete this attachment was generated at 2010-05-21 16:12:58 EDT.
Created attachment 169564 [details] Angelo proposed this solution for enabling remote launching with the existing DLTK infrastructure
