This is a blog like article with a FAQ for d3web developers transitioning from Eclipse to IntelliJ IDEA:
Download the attached code_styles.jar and import them with File -> Import settings.
Download the attached copyright.txt and add it the following way:
The provided copyright.txt is for the denkbares GmbH, but can easily be changed to other firms or e.g. the university.
Go to File -> Settings -> Version control -> Confirmation -> When files are created. You're probably looking for "Add silently".
Edit -> Macros -> Start macro recording
Now we record the actual macro simulating our Save actions:
Edit -> Marcros -> Stop macro recording
After that, I bound the macro to "Cmd + Alt + S". This way I still have the normal save, but also the macro which does more...
Use View -> Quick Documentation or the corresponding keyboard shortcut (depends on OS and Keymap).
On Mac OSX with Eclipse keymap, F2 Works.
It's also possible to enable automatic JavaDoc popup on code completion in Preferences -> Editor -> Code completion (Autopopup documentation).
At the beginning this worked for me (somewhat clitching), but now it no longer works :(
Unfortunately JUnit in IntelliJ IDEA has a different path for executing JUnit tests in modules as it will have when testing in maven builds. You can change this unwanted default behaving by setting the default JUnit path in the Run Configuration default settings for JUnit:
Open Menu Run->Edit configuration and there go to Defaults->JUnit->Working directory and set the value to $MODULE_DIR$.
After that IntelliJ IDEA will set the relative path in all JUnits just like Maven.
To run the Headless-App-Tests in JUnit (e.g. for debugging), create/add a new JUnit Configuration. In the configuration, make sure to use the settings displayed below. Make sure you select the Working directory of the "KnowWE-Headless-App", and select the classpath of the module "KnowWE-Headless-App". "Test kind" has to be "Class" and "Fork mode" has to be "none", otherwise debugging is not possible.
By default IntelliJ has different order of import statements as Eclipse. To avoid having these change every time a class is edited in the different IDEs, we should adjust the order in IntelliJ. This can be done under Code Style -> Java - > Imports. The order should be:
The above order will not quite avoid all changes, since Eclipse seems to additionally add blank lines between all imports with different first path elements, but this seems close enough for now. I think since it is a code style, this should also be part of the code style settings, which are also attached to this site.
Attention: After adding files to your library, they become read-only in IntelliJ. You should only add files as global libraries that you will not change often. Otherwise you need to removed them from the library as long as you edit them or only use an external copy of the files.
During startup KnowWE/Tomcat often produces exceptions of the following kind:
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: com.ecyrd.jspwiki.auth.UserManager at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1970) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1894) ....
KnowWE still works, but the exceptions are annoying/irritating...
In eclipse it was possible to delete the work-folder in KnowWE-App, but in IntelliJ that does no longer work.
The solution is actually pretty simple, just deactivate session persistence in your Tomcat:
For developers migrating from Eclipse to IntelliJ, the default behavior of breakpoints in IntelliJ might be unexpected. While Eclipse only suspends the thread that reached the breakpoint, IntelliJ also suspends all other threads when a breakpoint is reached.
This behavior can simply be changed in the settings of the breakpoint: Open the breakpoints panel in the debugger an navigate to your breakpoint. Right to the checkbox "Suspend" select the radio-button "Thread" instead of "All". On the right side of the panel you can also make this setting the default.
IntelliJ does not have a view showing all current compile errors like Eclipse did, because it does not compile automatically on each change of the code.
For me, the best replacement so far has been the following:
If you now want to see all compile errors, e.g. after a "dirty refactoring":
To remove the dock entries that IntelliJ spawns when compiling or running Tomcat, append -Dapple.awt.UIElement=true to your Java VM options.