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)
Related
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.
If you are using Eclipse and your development server is running in the debugger, when you save your changes to this file, Eclipse compiles the new code automatically, then attempts to insert the new code into the already-running server. Changes to classes, JSPs, static files and appengine-web.xml are reflected immediately in the running server without needing to restart
plz any one can explain this ??????????
For classes like JSP-files:
Its debugging using JPDA.
The IDE attach via socket to the JVM your running app and hot-redeploy the not-permanent-code (aka PermGen).
There are different techiques and frameworks for that:
http://en.wikipedia.org/wiki/Java_Platform_Debugger_Architecture
It doesn't happen automatically. Check Project --> Build Automatically option. It should have been checked.
If you un-check it; then project will not be build/deployed automatically.
I'm having trouble with a PHP project using Yii framework.
My setup is the following: Win7 + Eclipse4.2 + PDT 3.1 + Yiiclipse PDT extension + WAMP Server with XDEBUG enabled.
Pretty much everything works ok. The debug session starts, it's going through project's index.php source, but when it has to jump to framework's files, it doesn't open them up. I edited source lookup and added framework's local path but it simply cannot find them.
Here is a screenshot: http://img607.imageshack.us/img607/3687/eclipsepdt.png
This isn't necessarily an answer - but your question isn't necessarily a question either, so I feel like this is fair game :D
I've had so many problems with Eclipse PDT + xdebug in the past with debugging, code completion, etc., that I gave up on it a while ago and switched to Netbeans for PHP Debugging. It's now the defacto standard on my development team for debugging PHP; even though we all still have our own favorite editors, when we need to debug we'll still use Netbeans.
Code completion, phpdoc 'tooltips' on completion, and debugging all work flawlessly for me regardless of what platform I'm developing on (Windows, OS X, Linux) and I cannot say the same about Eclipse PDT (code completion would often miss, I'd run into problems or crashes debugging,etc.) in my personal experience.
So, I apologize in advance if this is a non-answer to a non-question - but maybe try out Netbeans?
Are you sure, you can use Xdebug to debug Yii (or any other framework-based) applications at all? Since Yii introduces URL-rewriting based on MVC pattern, I think you can't.
I don't have much experience with Xdebug, but from what I have found I clearly see, that it (along with Eclipse PDT) strongly depends on URL shown in Eclipse's internal browser, when debugging.
So, taking for example an URL from your screenshot:
http://localhost/testdrive/index.php?r=dispozitive
As you mentioned, Eclipse has correctly opened index.php, which is normal, as it is directly referenced in URL and you problably pointed it out as start file in debug configuration window.
Buth going further. How would you like Eclipse to understand, that route dispozitive (where route itself is a completely Yii concept (or similar framework) and Eclipse / Xdebug / PHP knows nothing about it) or that ?r=dispozitive URL parts corresponds to executing protected/SiteController.php file in your file system and calling default actionIndex() from it? So it could know it should open it in IDE and possibly stop execution on there defined breakpoints.
This process and concept (routing) is 100% authored by Yii and done by it internally, so how would you like Eclipse or Xdebug to know anything about it?
As I wrote, I don't have much experience in debugging Yii applications, but from what I have found until know, I clearly see, that you can't debug PHP applications with Xdebug, if they are using any kind of URL-rewriting methods. This technique (debugging with Xdebug) works IMHO only in case of applications, where URL changes directly reflects files in filesystem in your application contents.
EDIT: Additionally, check which version (package) of Eclipse you have? It turns out, that Helios package has some bugs and doesn't stops on breakpoints. Which makes it pretty useless for debugging process. You should consider using Galileo Package Eclipse for PHP Developers instead.
I'm ramping up on Vaadin and I'm getting this javascript alert whenever I try and run the demo apps.
GWT module 'com.vaadin.terminal.gwt.DefaultWidgetSet' may need to be recompiled
I've tried cleaning the project to no avail.
As I said, I'm ramping up so I'm sure there's some simple step I'm missing or a concept I haven't grasped.
I don't know anything about Vaadin, but there's a more general context in which this error occurs:
So long as you're testing in Eclipse, the dynamic coding of your app is still real Java coding being run in a JVM. This coding is made available through debugger that's accessible via a socket. You get a URL that looks like this:
http://127.0.0.1:8888/MyApp.html?gwt.codesvr=127.0.0.1:9997
with this codesvr thing being your eclipse-hosted debugger process for your Java code.
Before your app can run standalone, GWT has to translate your Java code to JavaScript; separate versions of the code are produced for each browser type (Firefox, WebKit, Opera, ...) and language that you want to support. Only once this is done can you access your app the usual way via
http://127.0.0.1:8888/MyApp.html
After weeks of running my app only in Eclipse, I'd managed to forget about the compiling-for-browsers step and wondered about the message. The way to fire up the compiler, if you're not using the Ant task, is to hit Google|GWT Compile in the project's context menu. That done, the JS in your app gets fleshed out and your app can run without Java on the client side.
And of course the message goes away.
It is a warning not an error. Does the app work? Otherwise you have to recompile the Vaadin widgetset. These might help too: http://vaadin.com/directory/help/using-vaadin-add-ons
Often this message meens:
you're missing the ?gwt.codesvr=127.0.0.1:9997 parameter in the URL (or have misspelled it).
your module uses the xs linker <add-linker name="xs" />. This is a known limitation and will be fixed in the future: Issue 4232: Allow Development Mode to work with XS Linker
You may need to clear the browser cache. It is possible that the compiled js that the browser is using is not the js that has most recently been compiled.
In Chrome you can see if the cached js is being used in the developer tools windows (ctrl + shift + i). In the size column it will say (from cache) instead of the actual size. You can then right click and clear the browser cache. ctrl + r to reload and the error should be gone.
Carl Smotricz is absolutely right.
Just Cleaning and Build Project on the topmost menu doesn't work.
You must use "Google | GWT Compile" on the context menu generated when right-clicking on your GWT project, prior to deployment.
The error may not be about not-adding "?gwt.codesvr=127.0.0.1:9997" at the end of host web page if he or she tried to deploy the GWT-based webapp on WAS external to Eclipse.
Server restart did the job for me.
I had tried clearing cache, clean and rebuild .. but i was still getting the same warning message.
Server restart made it reload all the stull from the latest compiled war.
It was a hit and trial and i am glad it worked :) :)