[Lucene-java Wiki] Trivial Update of "HowtoConfigureIntelliJ" by ErickErickson

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucene-java Wiki" for change notification.

The "HowtoConfigureIntelliJ" page has been changed by ErickErickson:
https://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ?action=diff&rev1=27&rev2=28

Comment:
Added remote debugging instructions for using the start scripts

  === Code Style ===
  If you use the "ant idea" target, the correct code style file will be automatically installed. But if you simply '''must''' do this yourself, use the link below. You'll have to change the file a bit for it to show up in your drop-down...
  
+ <!> IntelliJ 14.1.3  (and perhaps earlier) doesn't automatically install the code style file as of 22-May-2015 so you should do this manually. You'll see a very annoying dialog box pop up that talks about indenting being 2 spaces rather than 4. Solr/Lucene use 2-space indentation.
+ 
+ <!> IntelliJ (and other IDEs) have a nifty "reformat code" choice. IntelliJ has a ''very'' nifty checkbox in in the dialog box that pops up "only VCS changed text". Please use this! Be careful you don't reformat the entire file though, that's rarely A Good Thing as it makes diffs very hard to read.
+ 
  The IntelliJ anonymous code style file is here: ([[http://people.apache.org/~erick/Intellij-Lucene-Codestyle.xml|Intellij-Lucene-Codestyle.xml]])
  
  === Debugging ===
@@ -36, +40 @@

  
  However, it is ''strongly'' recommended that when you develop new code you also create unit tests, so if you're developing new code this is very often the easiest way to step through code.
  
- The second way is to create a "remote debug" session. To debug remotely, follow the instructions above for setting up IntelliJ. Then, in the <solr_home>/solr directory, execute "ant example". So far it's easy.
+ The second way is to create a "remote debug" session. To debug remotely, follow the instructions above for setting up IntelliJ.
  
  Next, in IntelliJ, create a remote debugging session. Do do this, there's a little click the chicklet and then the "edit configurations" setting. Now, click the little plus sign and click "remote". This will bring up a dialog and enter the host and port, usually "localhost" and "some port", I use 5900.
  
@@ -45, +49 @@

  -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5900
  }}}
  
- You take that string and use it to start solr by going to the <solr home>/solr/example and entering something like:
+ <!> Solr 4x <!> You take that string and use it to start solr by going to the <solr home>/solr/example and entering something like:
  {{{
  java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5900 -jar start.jar
  }}}
  
+ <!> Solr 5x <!> For the new script-driven (Solr 5.x) start/stop, you can start Solr in debug mode with something like the below. This particular example will start up a node in a SolrCloud setup for debugging, of course for stand-alone you can just leave out the '-c -z localhost:2181' bits and point the -s parameter appropriately. Usually it's easiest to set up the instance with, perhaps, one of the examples (-e option), stop the instance, then start up a debug session like below once the structure has been created.
+ {{{
+ bin/solr start -c -z localhost:2181 -p 8981 -s ./example/cloud/node1/solr -a "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=6900"
+ }}}
+ 
  Now go back into IntelliJ and execute the configuration you just created. At that point, you'll be able to set breakpoints in Solr and all sorts of good stuff. One note here: setting "suspend=y" in the above causes the Solr instance to wait around and do nothing until you invoke the remote configuration in IntelliJ. If you set "suspend=n" in the above, then Solr will start up and load all the configs etc. You can still attach the debugger and set breakpoints which you'll hit when you execute the code path. This process seems more complex than it really is, but at that it is far easier than starting up the servlet container within IntelliJ. The downside is that to make code changes you need to re-build Solr after making changes and attach again. Which is why jUnit tests are such a good idea.....