Showing posts with label IntelliJ. Show all posts
Showing posts with label IntelliJ. Show all posts

Tuesday, May 20, 2014

Debugging gradle jettyRun in IntelliJ

I was trying to figure out how to attach a debugger to the jetty server launched by running an app from gradle jettyRun. It turned out not to be so straight forward, but here's what I did.

Step 1 - Upgrade to IntelliJ 13 if you're not there already. The gradle support has significantly improved.

Step 2 - Create a new Jetty Server (Remote) configuration. Gradle uses an embedded jetty server, but you need to point IntelliJ at the home folder of a Jetty installation. I downloaded Jetty 6.125 (Gradle 1.10 uses Jetty 6, this may change with newer versions) and pointed at that.

Step 3 - Configure the Jetty Server. I used the following values, but your may change them as needed.

Server tab:
- Application Server: Jetty 6.125
- JMX port: 2099
- Remote Staging type and host are both Same file system
- Remote connection (where your app is running) defaults to localhost:8080

Startup/Connection tab (Select Debug configuration):
- Port: 52252 (default)
- Transport: Socket (default)
- The window will show the parameters you will need to pass to GRADLE_OPTS (or however you get properties to gradle, such as through gradle.properties). These properties are in addition to other properties in gradle.

Step 4 - Create (or modify your existing one if you have) a jetty config file and point your jetty tasks at it as shown in http://blog.james-carr.org/2011/12/20/enabling-jmx-in-gradles-jetty-plugin/. I did not have a jetty-env file.

Step 5 - Start your gradle process from the command line with the following opts (or again here, in gradle.properties):

export GRADLE_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sumanagement.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -DOPTIONS=jmx -Xdebug -Xrunjdwp:transport=dt_socket,address=52252,suspend=n,server=y -javaagent:/opt/idea-IU-133.1122/plugins/Groovy/lib/agent/gragent.jar"


Note the -Xdebug and opts after that come from the arguments in the Startup/Connection tab in Step 3.

Step 6 - Once your app has started, start the jetty configuration from IntelliJ in Debug mode. Run your webapp, and your code should now stop at breakpoints in IntelliJ. Very many thanks to the StackOverflow's @CrazyCoder (http://stackoverflow.com/questions/14825546/deploy-debug-remote-jetty-with-intellij-12) and James Carr for his blog post referenced above.

Friday, February 15, 2013

Why I switched to IntelliJ

For the last few years, I have been an Eclipse user. It's free, and for the most part, it worked pretty will with the occasional crash. However, I've found that it performs really poorly when it comes to dynamic languages. The groovy/grails autocomplete is mediocre, but where I really had issues is with Javascript. It got to a point where every time I tried to save a Javascript file, I was getting a NullPointerException.

So I decided to try out IntelliJ Ultimate based on a colleague's recommendation. Overall, I've been happy with the experience. It is very stable (I've only had one crash since I've been using it, and I was running a lot on my system at once). Deploying to Tomcat servers has been a breeze.

It's not without its quirks though. For example, things that just work in Eclipse, such as auto-wrapping long comment lines, don't work in IntelliJ. I've also found that the gradle support is still new and can be buggy at times (especially with auto-synchronizing Intelli's dependencies with the gradle build's dependencies - though I've heard that's in the works).

What I've been most impressed with is the support. Whether on the Jetbrains forums, bug tracker or stack overflow, the IntelliJ support team generally responds very quickly to posts.

Overall, it has been a pleasant experience. If you're fed up with Eclipse, I recommend giving IntelliJ a try.