We have an Jenkins CI, which creates our Eclipse RCP application. It was set up with this tutorial: http://www.ralfebert.de/blog/eclipsercp/rcp_builds/ . So far so good, we didn´t have any problems until we decided to use utf-8 encoding for our project instead of the default cp1252 encoding. So the problem is if we start the created application that the encoding is damaged. I tried everything especially with jvm -dfile.encoding="utf-8" arguments. I tried this in rcp.target, jenkins arguments and build.xml build properties.
Have someone any idea how i can fix my problem?
thanks for every response
We have the same issue as well, unfortunately unsolved so far. I think the charset must be set in time of compilation. So this may be a jvm argument instead of program argument.
Make sure you have saved the encoding information in the project. If there is no such information, the eclipse instance default encoding will be used, which in turns defaults to the platform's default encoding.
Buckminster build uses the eclipse build which honors the resource meta data.
An anti pattern is to change the default in Eclipse, and not save it in projects. The next user with a different default then risks creating a complete mess, especially if they also change the default and save.
Related
I have an independently written LSP-compliant language server for a custom language and an Xtext framework for that language, as Eclipse plugins. The two work fine independently; the LSP is connected in using LSP4E.
But when I try to connect the Language Server into a project in which Xtext is providing syntax coloring and some parsing checking, it appears that the language server is never started and certainly is not providing the error messages to the Eclipse UI that it does when used by itself. I'm not asking Xtext to create a language server itself.
The goal is to use (and not reimplement) the LS for parsing and type checking and language-aware code navigation, while using Xtext for syntax coloring.
Can anyone point me to a successful use of these two technologies together? or know that they cannot (yet?) be?
Edit: To the comment about checking whether the LS is working. As far as I can tell, the LS is not even started, though it started fine when used alone. Somehow putting Xtexxt into the mix has usurped the connection to the LS or changed it in a way that the launching and use no longer happens.
The LSP4J version installed is (only) Eclipse LSP4J org.eclipse.lsp4j 0.15.0.v20220805-0131 org.eclipse.lsp4j
Xtext's components vary, but basically Eclipse Xtext Xtext 2.28.0.v20220829-0438 org.eclipse.xtext
I'm trying to run a JavaFX application to test some custom controls based on jdk14 and JavaFX14. My operating system is Windows 10, the IDE is Eclipse 2020-03, and I use m2e Maven plugin. The controls are exact copies of controls developed under jdk8 and JavaFX8; the earlier controls pass all tests, there was no problem with debugging.
There is no problem getting a test application to run using jdk14 and JavaFX14, but breakpoints are ignored regardless of whether I run in debug mode, or run mode, or whether I modify the Maven command from javafx:run to javafx:debug (that did NOT work) or to javafx:run#debug.
This issue seems to have been addressed several times in the context of a Netbeans IDE (see stackoverflow discussion, and I copied in the text from the modified plugin as suggested, but to no effect.
I have the following questions:
What must be done in order to debug a JavaFX application under the conditions described above?
Who is responsible for dealing with this? Eclipse? OpenJFX? Somebody else?
Based on the principle that whatever solution is developed, it should be as user friendly as the debugging process under jdk8 and JavaFX8 (i.e. before JavaFX and everything else got decoupled from Oracle), is it reasonable to expect that a solution along those lines will be available in the near future? Is anybody working on it now?
Thanks for feedback.
I have recently started developing an Eclipse plugin (which is basic stuff for now) and I am struggling with "default" way to run Eclipse plugin ("Run as Eclipse application").
The Eclipse is starting another instance with my plugin already installed in it (this is default behaviour).
The problem is that when I want to re-run my plugin project and I press "run" button again (or Ctrl + F11) (and the another Eclipse instance still running) I get following message:
"Could not launch the application because the associated workspace is currently in use by another Eclipse application".
The error makes sense, and when I close "testing" Eclipse instance I am able to run my plugin again.
The question is - "is it normal routine for plugin development?". Maybe I am missing something, e.g. special arguments for Eclipse?
This seems all pretty normal. The error message is since the run configuration is specifing a workspace and when you start a second instance using the same workspace it is locked and considered in use.
What I usually do when testing a plugin is to create a run configuration (click "Run...") where I disable all the plugins I wont need when testing. This makes sure that the test starts up a couple of seconds quicker. Make sure you save that run configuration as a *.launch file aswell, that makes it quicker to test the next time. Or it can be used to share the configuration.
There's a lot you can configure in the run configuration, such as eclipse arguments, vm argument, if you want environment variables set, etc. So be sure to experiment a little.
In your run configuration. Main tab->Workspace Data ->Location text box add this:
${workspace_loc}/../runtime-EclipseApplication${current_date:yyyyMMdd_HHmmss}
Note the suffix ${current_date:yyyyMMdd_HHmmss} by this every time you launch your application new workspace will be created. So you will not get any error message saying workspace is locked.
But be careful as the folder .metadata will be different for different instances as their work-spaces are different. Thus preferences stored/retrieved by different instances are NOT in sync.
You are probably missing one important point: Eclipse supports the Java hot code replacement. Therefore in many cases you can modify your Java code while your application Eclipse instance is running, save the code and continue without restarting.
If hot code replacement is not possible, Eclipse will tell you, so you always know whether the editing changes are applied to the running instance.
This works best with more recent versions of the JVM, so consider upgrading to the latest Java 7 version, even if you write code to be compliant with Java 1.5 or 6.
I've got a Android AppEngine Connected Project I'm trying to build using GWT2.4 RequestFactory and Objectify on my Eclipse IDE.
Apparently I need to run the RequestFactory Validation Tool because I'm using ServiceName and ProxyForName annotations (these are required especially when working on the Android client side). My problem is the Eclipse can't validate it and the solution provided at http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation#IDE_configuration is enough to make me rip my eyes out.
Since I'm working on a Windows machine, the shell script provided is not very useful. Trying to run Validation Tool from a cmd propt returns the error message:"This tool must be run with a JDK, not a JRE"
Can someone explain how this Tool is supposed to be run? Is there a way to use it as an External Tool in eclipse?
Normally if you follow carefully the instructions in the link you show, and run the GWT Development Mode from Eclipse, the Validation should be done automatically at the time you access the development URL with your browser.
For the record, I've actually had some problems with it, but launching the application several times maked it work.
Well, I ran into the same problem as well. When I tried annotation processing (under Java Compiler-> Annotation processing )was being disabled. So RequestFactoryDeobfuscatorBuilder was not being generated. Try enabling that and rebuilding your project.
I've just recovered from two days of hunting this bug down in a project that used to run validation properly but stopped.
In my case I had a new-ish generic BaseRequestContext and a specific sub-interface that extended it. My parent interface declared a method that didn't match the Locator's exactly (e.g. getThing(T) vs get(T)) and this wasn't reported as an error but did stop the validation tool from completing.
Apt is also removed in Java 8 : http://openjdk.java.net/jeps/117 . So beware.
Switching back to Java 7 will fix the issue if you are using Java 8.
I understood why the error happens sometimes in a project: the compiler was complaining it cannot find the directory .apt . But when I tried to create it manually it was not possible (under windows). I think the validation tool mutes the exception of not being able to create the directory: try renaming .apt in your validation tool calls (do a text search in your project)
We have files that should be executable, and are happily executable in git, but then editing and committing the file from Eclipse on Windows results in the file mode being changed to remove executability.
This happens regardless of whether core.filemode is set to true or false.
Basically egit seems to be too naive for our purposes (breaking file permissions is the problem, but it also doesn't seem to support git-svn) so we're using msysgit instead - we have to manually refresh in Eclipse after switching branches etc, but that's a small enough sacrifice compared to it breaking our code.
There are recent fixes for the filemode problems post 1.2, e.g. use the nightly build.