How do I prevent superDevMode from appearing in my arguments? - eclipse

I'm using Eclipse (Kepler) for a GWT application and for some reason, superDevMode keeps appearing in my arguments. We are stuck with GWT 2.4 which does not know what superDevMode is. I remove the argument, hit Apply and Debug to start the app, but when I look at the arguments again, -superDevMode is in there again. I am assuming there is some property that belongs to 2.6 (the version that was installed with the Eclipse plugin), but I can't seem to find it.
Update: Below, Adam recommended that I go to the GWT tab and take it out of superdevmode. Here is a screenshot of that tab:
There isn't a way to do that. The large area at the top of the tab (above the Super Dev Mode group) suggested that something was supposed to be there, so I set the project's GWT to 2.6. Sure enough, there was a Super/Classic dev mode selection. I set it to classic, saved the settings, and then put the project back to 2.4. The GWT tab looked exactly as it does above and the arguments now has "-nosuperDevMode" in it, which is also not recognized by 2.4.
Any help would be appreciated.
Thanks,
CC

I found a temporary workaround that comes with a caveat: I made the Eclipse Run Configuration file read-only.
Example path:
<YOUR_WORKSPACE>\.metadata\.plugins\org.eclipse.debug.core\.launches\<YOUR_RUN_CONFIG_NAME>.launch
Then whenever you bring up the Dev Mode Run Configuration in Eclipse it still shows the -superDevMode flag, but when you click the Close button it now asks you if you want to save and you can press No.
The big caveat: if you actually do want to change the Run Configuration Eclipse will ask if you want to save, you press Yes, the dialog closes, but it didn't actually save.
Easiest fix is to shutdown Eclipse, manually edit the .launch file to remove -superDevMode, make the file read-only, then start Eclipse again.
Here's the bug report.

Go to GWT tab (3rd from left) and switch from Super Development Mode to Classic Development Mode

Related

Eclipse start with previously set (un)folded methods

I frequently use folding/unfolding of methods in Eclipse for Java while working. However after each launch of Eclipse I need to redo the settings of folding/unfolding methods. Is it possible to make the framework "remember" my settings in each opened file? By folding/unfolding I meen clicking (+)/(-) button as on the following picture:
Please note I do not want all methods to be folded or all to be unfolded. I want the fremwork to remember my settings.
Although Eclipse doesn't natively support the remembering of folding/collapsed state of its editors, you can use external plugin to do the same. Here's a plugin that might help you with your problem.
Eclipse Folding Plugin

How to link Eclipse editor window to Eclipse project

I'm running into an issue in Eclipse where the editor pane is not linked to the project in the Package Explorer window. For instance, if I click on a project in the package explorer and then open a Problems window that is set to Configure Contents > uncheck Show all items > set Scope to On any element in same project, it will show any applicable errors or warnings, but as soon as I open one of the class files with an error/warning in it, in the editor pane, the problems list goes blank as the editor pane does not appear to link the active tab to the active project. Simply clicking the Package Explorer window will then repopulate the problems tab until focus goes back to the editor window/tab.
This used to work with older versions of Eclipse, but ever since I updated Eclipse, it no longer does this and I don't recall which version it was that I had been using. I've also downloaded a completely clean copy of Eclipse Luna (latest version) and simply imported the old projects and still the same issue.
Is there any way to change it so the active tab in the editor points to its associated project? It's quite frustrating having to click the Package Explorer window every time I want to look at a list of problems or tasks for a specific project.
Edit: I've narrowed the issue down to minimized windows only and provided an example of the issue below.
Both windows are restricted to "Show issue on project" rather than showing all issues. Notice how the "Tasks" window works as intended while the "Problems" window does not.
Found the issue... sort of. Apparently, if you minimize the problems tab, then try to access it via the minimized icon for the tab, it loses the correct focusing to tell you what the problems are. My previous version was setup in exactly the same way and had no issues, so they must have changed something that broke this. Going to look at submitting this to the Eclipse team, as a bug.

How to avoid Eclipse blocking keyboard shortcuts

I installed a plugin that allowed me to create UML diagram from my code. Everything was working fine until I found that now all keyboard shortcuts (like CTRL-X, CTRL-Z, CTRL-SPACE, CTRL-SHIFT-F,..) except for CTRL-C and CTRL-V now require a click on a small square that appear on the bottom right corner. And this is required every single time.
This are few examples of the square that appears:
If I click on the message or press Enter I can access the functionality. Does anyone know how to get rid of this annoying thing or at least reset Eclipse related configurations?
Thanks in advance
EDIT:
I obviously tried uninstalling the plugin but nothing changed.
Try Window / Reset Perspective as the duplicate shortcuts may be still in the perspective.
Also try restart specifying -clean option to rebuild the workspace metadata.
The pop-ups you are seeing are the "keybinding conflict" popups. These are common when you have two different plugins defining the same keybinding and looks like these. Still in your case there's only one option to choose from and it definitely looks like a bug.
In the Eclipse bugtracker database there are two issues that are looking like the one you have: #377048 and #374942.
These issues are marked as fixed in 4.2-I20120410-0633. So if you are having Eclipse 4.2 without any service releases installed, you would probably have this. The solution is - to use a newer Eclipse version. Eclipse 4.3.1 is available to download since today, and it should contain a lot of other fixes since 4.2. So I encourage you to install it.
The other solution could be to try playing with keybinding dialog (Window->Preferences->General->Keys) and trying to unbind and re-bind the commands that you are having issues with.

Speeding up PDE edit-compile-debug cycle

Are there any low-hanging fruit regarding some more efficient way to run and test Eclipse-plugins (within the PDE)? Besides slimming down the Eclipse-configuration, which has already been done.
I usually minimize my launch configuration itself (not sure if that is what you are doing). Here's how I do it:
Create a new launch configuration
Go to the "Plug-ins" tab
Select "Launch With:" -> "Plug-ins selected below only"
Click on "Deselect All"
Select only the plug-ins you are debugging from your workspace
Optional: You can uncheck "Include optional dependencies..."
Click on "Add Required Plug-ins"
Save the configuration and launch
Now, this might not work in the first shot. This probably means you have an issue with the defined dependencies. This is also a good test for that as well. Fix it, relaunch, and it should run much smoother.
I use Launch As: Eclipse Application and I don't find it to be too bad. I've found that changing the plugin.xml (or fragment.xml) always requires you to quit and respawn to pick up the changes, but changing Java doesn't always as the changes can often be hot-swapped in. (PDE is good at warning you when it can't.)
I'd like it if Eclipse could dynamically insert my plug-ins into the running environment -- it can do this with regular plug-ins. As for speeding up the edit-compile-debug cycle, I normally prototype my work in small SWT / Swing applications before integrating them into the full product, but this might not work in a lot of cases.

Setting breakpoint w/Eclipse PDT

I am SOOOOO discouraged. This seems so simple, but being a complete novice in Drupal and Eclipse PDT I have absolutely no idea where to look. My DAYS of searching seems to indicate that I am the only person on the planet with this problem.
Eclipse IDE for PHP Developers (1.2.1.20090918-0703)
WampServer Version 2.0
Apache 2.2.11
PHP 5.2.9-2
MySQL 5.1.33
Drupal 6.15
xDebug php_xdebug-2.0.5-5.2.dll
I setup my project in Eclipse to point to my Drupal directory (C:\wamp\www\drupal-6.15). I start the debugger (xdebug) and I stop at the first line of code. I can step through the code line by line -- so I think I am in the debugger, and when I terminate the app, I see the xdebug termination message in the tab heading.
But I cannot set a breakpoint in any of the PHP code files -- specifically a new .module file.
When I right click in the breakpoint column on the left in index.php (main) I see "toggle breakpoint" and the little blue circle next to the line of code...so I think I know how to set a breakpoint. But when I try to set a breakpoint in my .module, I see a menu that asks me to "add a bookmark" and no option to set a breakpoint.
Why can I not set a breakpoint in this file? Is my project path not set up correctly? Do I need to amend my include path? I can't get Eclipse to recognize even core modules not just site/all modules. I've seen posts about "importing" files into the project, and making sure the correct php.ini file is used for configuring xdebug. I'm lost.
There are so many posts about using Eclipst PDT and xDebug and they all end with "have fun debugging" or "just set some breakpoints and off you go" -- but what if you CAN'T set a breakpoint? Any ideas about where Eclipse is lost? Where in Eclipse can you get a list of files it has included in its build?
I think I just need to know understand why Eclipse cannot find these modules within the project (i.e. drupal application) path to allow me to set breakpoints. Then I think I can carry on. So discouraging...
Thanks to anyone listening.
Thanks for the tip. I think I had seen your similar response in another post somewhere.
Actually, the solution for me was to make sure to include all of the standard Drupal file extensions in the Eclipse file associations preferences: Preferences->General->Content Types->Text->PHP Content Type. The defaults are various *.php, *.phpX, *.phtml extensions, but not the extensions used in Drupal modules -- *.info, *.inc, *.module, *.install, etc.
Simple and obvious once you figure it out. I'm surprised with all the Eclipse-xDebug-Drupal setup instructions out there that this had not shown up. Lots of details about matching project paths with server paths, but nothing about this.
I hope my struggle helps someone. I did learn a lot about Eclipse PDT along the way :-). Good luck.
Breakpoints are tricky in PDT projects:
for php files, you need to be careful
One thing that gets me a lot is that there a lot of "invalid" places where you set breakpoints. You can put the dot there in the IDE, but the debugger won't stop at it:
blank/non-code lines
on switch statements
in some types of callbacks (for example, preg_replace)
But for breakpoints in .module files, this should be related to a setup issue.
I made the following changes to my setup:
Upgraded from php 5.2.1 to php 5.2.3
Installed the Zend debugger client in Eclipse/PDT (theoretically not necessary from what I understand, but I decided to give it a try)
Made sure that the Drupal files were fully imported into my project, not just referenced as include libraries.
I did that last step after I created a tiny test case and discovered that I could get the debugger to stop on a breakpoint in an externally included file only if that file was imported into the project, not if it was referenced as part of an include library directory.
To my mind this seems like a bug - the debugger could certainly see that the files in the include library directories were source files and it let me set breakpoints in them, so it seems that it should stop on them.
(For comparison from a separate (java) IDE, IntelliJ will let you define breakpoints in jar files as long as you tell it where the source is. Once you've defined it, it will stop on it.)
I think it was principally that last step that did the trick, so I'd suggest that anyone else with a similar problem make sure that isn't an issue in their setup first, and then try the other steps.
check whether you opened your java file in java editor mode.
ie ctrl+shift+R, in this popup check the button beside OPEN option and select java editor.
The problem of not being able to set a breakpoint can occur if you have recently created a file. You must close and re-open the file for it to be recognised as a source file that can be debugged, and to enable the code highlighting.