JAYlib Wiki

As mentioned in the License Agreement of the plug-in: it is the Apache 2.0 license. Sorry - the eclipsecall.jar and any client implementation offered here are only Examples. As Eclipse is used primarly by programmers anyone can write his/her own client call. The major thing offered here is/are the eclipse-plugins, not its client applications.

eclipsecall.jar will not launch eclipse for me (on Linux) using "-E/path/to/eclipse".

Also, the eclipsecall.jar utility expects environment variables with a period in their name, which is not allowed by BASH or any modern shell. Please fix this so that it uses standard variables such as ECLIPSECALL_SOCKET, ECLIPSECALL_EXE or something similar. I tried changing it myself, but it still did not launch eclipse when it was not running.

Ideally, I would like to use the same script to both launch eclipse and open a file in a running eclipse process. (e.g. eclipse should launch even if eclipsecall is called with no parameters) Thanks for your work on this, it is very useful!

Thank you for this plugin. It is a great help.

Just to make everybody aware, there are two Eclipse Bugzilla bugs discussing the feature:

   https://bugs.eclipse.org/bugs/show_bug.cgi?id=4922
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=178927

It would be very important to know under what license the code here is distributed? - Neither eclipsecall.c nor CallClient.java carry any Copyright header. It's impossible to adopt that code into any commercial product unless the Copyright owner and license under which it is distributed is clear.

Putting it in the Public Domain, under a BSD license or under the EPL would be preferred: http://www.opensource.org/licenses

... but this was only a sample implementations anyway

Ok, here is the trick to get it working with Mac OS X:

The full call will be for example: `java CallClient /Users/Xxx/Eclipse/workspace/eclipsecall/src/CallClient.java -E/Applications/eclipse/Eclipse.app/contents/MacOS/eclipse`

Eclipse will open (with) the file And if the project is open, it will even know it's the file from the project

I would like to recommend JayLib to add a little hint (else construction) to the `if (eclipse != null) {` check, as this seemd to be the problem in my case. Next, I needed to install both the basic and IDE before it really worked.

Just tried this on win xp with ganymade sp1 but nothing seems to happen after runnen the lib with a file as argument. Is sp1 not working yet? No errormessages.

Hi there,

Great idea! Hopefully eclipse will come with a solution for this issue themselves, until then: great job.

I can't seem to get it working on MacOS X though. The plug-in installs, but the jar file just doesn't do anything. Is it possible to activate some form of debugging so we can find why it isn't working?

• Mac OS X 10.5.6
• Eclipse Version: 3.4.1
• org.jaylib.plugins.eclipsecall_1.2.0.jar
• java version "1.5.0_16"

Excellent! My silly build tools always use the line argument, even if there is no line number. For example, clicking on a file generates the command:

eclipsecall.exe file.c -G

and clicking on an error generates the command

eclipsecall.exe file.c -G34

I can't make my build tools omit the -G option if there is no line number. eclipsecall opens the file, then highlights line 1 if -G is used with no number. A better behavior (for me) would be to ignore the -G if there is no line number given.

... should get assigned different sockets. I know that sockets are no optimal way and the concept of sockets fails, if you try to open a server socket an the same port again. The output should be seen, when running eclipse with the -consoleLog option. Opening a range of ports does not yield constant behavior - this could be done however. I wouldn't like to have a file I double clicked pop up once in that eclipse and once in the other (where the file type probably is not even supported) or even worse: in the eclipse instance of another editor. So maybe there should be a server registry for both server and client running only once on a specialized port... could be a bigger project... I think that could get pretty complicated! Maybe after my holidays... Anybody feeling free to port the code may do so however.

OK - for developers I should add a feedback (maybe a listener) about the current state after opening the port: if it failed or succeded.

It would be nice if the plugin piped all of its error output to the standard Eclipse error log (however one does that). We have a number of developers running on the same server and (obviously) only the first Eclipse instance launched manages to open the server socket on the default port. There is no indication to the subsequent developers that the plugin failed to open the socket. Is it possible to have the configured port be interpreted as a hint? If you also provide support in the EclipseCall preferences panel for entering a port range size, then the plugin can try to open a port in the range until it succeeds. The number of the successfully opened port would then have to be displayed somewhere on the preferences panel.

Also, it would be nice to have a control in the preferences panel for stopping/starting the plugin (i.e. closing/opening the server socket).

just made an update. The problem was one misinterpretation of a routine, that computed the marker for the marked line. This bugfix is only relevant for the IDE-part of the plug-in.

I have this working in my RCP application now. Michael made a few enhancements at my request so it would be easier to integrate with an RCP application.

I created my own .exe wrapper for eclipsecall so I could set different defaults for the -S and -E options for my RCP application (otherwise my Eclipse IDE keeps trying to open my app's files). Under windows my install image looks like this:

WizardsFamiliar

    .eclipseproduct
    WizardsFamiliar.exe
    WizardsFamiliar.ini

WizardsFamiliar/configuration

    <normal rcp stuff>

WizardsFamiliar/features

    <other features required by my app>
    EclipseCall_1.0.5

WizardsFamiliar/plugins

    <other plugins required by my app>
    org.jaylib.plugins.eclipsecall_1.0.5.jar

WizardsFamiliar/integration

    WFFileOpen.exe
    eclipsecall.jar
    WFFileOpen.reg

WFFileOpen.exe is my version of eclipsecall.exe and WFFileOpen.reg registers my application's files with the Windows Shell.

Here are the contents:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.deck]
@="WizardsFamiliar.DeckFile"

[HKEY_CLASSES_ROOT\WizardsFamiliar.DeckFile\]
@="Wizard's Familiar Deck File"

[HKEY_CLASSES_ROOT\WizardsFamiliar.DeckFile\DefaultIcon]
@="P:\\InstallImages\\TestInstalls\\WizardsFamiliar\\integration\\WFFileOpen.exe,0"

[HKEY_CLASSES_ROOT\WizardsFamiliar.DeckFile\Shell]

[HKEY_CLASSES_ROOT\WizardsFamiliar.DeckFile\Shell\Open]
@="&Open"

[HKEY_CLASSES_ROOT\WizardsFamiliar.DeckFile\Shell\Open\Command]
@="P:\\InstallImages\\TestInstalls\\WizardsFamiliar\\integration\\WFFileOpen.exe %1"

I saw the problem Bob Swift described below as well. The thing is: if eclipsecall.exe is the standard file opener (e.g. for Windows) for a given file type and within Eclipse the file type is configured to be opened by the system editor, Eclipse itself tries to open the file with the system editor, which is eclipsecall.exe, which leads to another opening of the same file and to the described hang-up.

For testing purposes I've made a new version available here (as update-site from Eclipse): URL: http://www.jaylib.org/eclipsecall

The described error is solved here by simply opening the DefaultTextEditor, if the file shall be opened by the SystemEditor.

Current version is 1.0.2 The normal User using EclipseCall with Eclipse, should check the "EclipseCall + IDE Integration". Developers, that want to extend EclipseCall for their own RCP application, may check "Eclipse Call Basic - Developer".

If I don't find any further issues, I will make it a bit more public

Michael

Michael,

This looks really interesting and just the kind of thing I need for my RCP based application. I looked at the source code and found that it will not quite work for me as is, since I am not using the org.eclipse.ui.IDE plug-ins to perform file managment. My application is not an IDE at all so my file management mechanism is not the same.

I have a proposal. How about re-factoring your plug-in into two plug-ins. One which provides the handling of the URL protocol and the connection from the eclipecall.jar. This plug-in would provide an extension point who's registered implementations will be called when a file is to be opened. The other plug-in would implement the extension point and use the IDE file open protocol. Therefore the two plug-ins would provide the functionality of your original version 1.0 plug-in. This way others could use your eclipse call infrastructure and implement their own open code to work with their RCP application.

I would be willing to contribute code to this as well (although I am not sure about my time frame). Contact me at XXX by mischu if you wish to have further discussions.

Ian

I just tried it with Eclipse (Europa) and Groovy, but I don't get any hang-ups... Any problems should probably be reported to me (mischu at gmx dot org).

Just noticed this. Something people have been asking about for a long time. Works good for me except for groovy files (hangs) for some strange reason.