Posts

Using AsciiDoc with IntelliJ IDEA

AsciiDoc is gaining more and more popularity compared to the competing markup languages like Markdown, yet one of the biggest complaints heard was that tooling support was inadequate. These days, however, support for AsciiDoc is available in popular editors like Atom, Sublime, Emacs, Vim, etc, and also in the most popular Java IDE, IntelliJ IDEA. This blogpost describes how to effectively use the plugin.

Installation

Installation of the plugin is easy. You can use the plugin browser (Preferences -> Plugins -> Browse repositories) and type asciidoc in the search. Alternatively, you can also open a file with an extension recognised by the AsciiDoc plugin (.adoc, .asciidoc and .ad). This will trigger an info message by IntelliJ informing you that there’s a plugin to handle these filetypes.

Features

Live preview
Once the plugin has been installed, one of the nicest features of the plugin is that Live Preview works. It’s a little bit cumbersome to setup at the moment, but it’s worth it. To enable live preview, you first need to open an AsciiDoc document. When a file is open in the active editor, go to Window -> Editor Tabs -> Split Vertically. This will open the same document twice. Now, click on the Preview tab at the bottom of the editor in either the left or right editor. Now you’ve set up Live Preview! Making changes to the text in one editor will now be reflected in the preview.

Syntax highlighting
Basic syntax highlighting is now supported by the plugin. For example, code blocks are highlighted, as well as titles, which makes editing documents a bit more easier and it gives immediate feedback if the syntax used is correct.

Toolbar
The toolbar is an incubating feature of the plugin, and provides easy access to often used shortcuts, like basic formatting, but also for creating tables.

Converting from Markdown
One of the unique features of the AsciiDoc plugin is to be able to convert from Markdown to AsciiDoc. The process for this is straightforward: when the AsciiDoc plugin is installed, right-click on a Markdown file, and select ‘Convert to AsciiDoc’. The Markdown syntax will be converted to AsciiDoc, and the file will be renamed from filename.md to filename.adoc. This feature has been used on numerous open source projects including Docker and Geb, and has proved to be a stable addition to the plugin. It’s also possible to use the Markdown to AsciiDoc converter in a standalone way or include in your own Java application, as explained here.

Live templates
To save typing, and get familiar with the AsciiDoc syntax, it’s now possible to use Live Templates. All live templates are prefixed with ‘ad-‘, so start typing ‘ad-‘ and you’ll see a list of all the AsciiDoc templates available, like tables, list items, includes, etc. Alternatively, pressing Cmd+J will also bring up the list of templates to choose from.

AsciiDoc live templates

Scratch files
Just want to make a quick note? Scratch files to the rescue, which even include the preview button. Scratch files are documents which are used temporary, and are not saved on the file system. You can create a new Scratch File by accessing Tools -> New Scratch File.

IntelliJ Live Templates with Google Guava

In this screencast, I will explain how to setup IntelliJ live templates with Google Guava, and how to add a bit a Functional Programming to your Java code when using Java 7 or below. The templates used in the video, including the configuration for them, can be found below.

The code to make the filter work, is the following. You’ll have to go to Preferences -> Editor -> Live templates and add a new template there. The following code need to be entered for the filter:

Filter

And the following variables have to be used:

Screen-Shot-2014-03-15-at-22.57.56-600x169

For the transformation, another template needs to be added, similar to the template above.

Transform

With these variables:

Screen-Shot-2014-03-15-at-22.58.18-600x228

If you’ve setup the above, functional programming will become a lot easier, even in Java versions older than Java 8!

Upgrading Grails 2.2.4 to 2.3.0

I’m currently working on a trivial Grails application, running on Grails 2.2.4. However, two days ago, Grails 2.3.0 was released, providing many new features, like testing with Spock by default, Hibernate 4, etc. However, when upgrading to 2.3.0 using

I received the following error:

I turns out grails upgrade doesn’t fix this for you (Thanks Tim!) (and, starting from Grails 2.3.0, it’s deprecated and replaced by use-current-grails-version), and you need to fix this yourself. It turns out the fix is quite easy; just add replace your Tomcat and Hibernate dependencies by this:

And it will work. Hope it’s useful, and remember to carefully read the docs, I missed it.

Update (14-10-2013): If you are wondering why debugging doesn’t work: you’ll need to start Grails with run-app --debug-fork
IntelliJ Update (1-10-2013) : IntelliJ 12.1.5 has been released, which now has support for Grails 2.3.0.
If you are using IntelliJ (12.1.5 EAP at the moment), you’ll find out that it’s not compatible with Grails 2.3.0. There’s an issue for that, which has been fixed. Applying the patches from the Youtrack issue will fix the issue and will make Grails 2.3.0 working on IntelliJ 12.1.5.

Generate a toString using Guava Objects.toStringhelper with IntelliJ

In IntelliJ it’s possible to generate a toString using Alt+Insert (Windows) or Ctrl+N (Mac). In this dialog, you can choose to use different implementations, like a StringBuffer, a StringBuilder, Apache Commons ToStringBuilder, and more. But if you’re using Google Guava, you can create your own template in IntelliJ. To do so, do the following:

  • Open a class file
  • Press Alt + Insert or Ctrl + N to popup the ‘Generate’ menu
  • Choose toString()
  • Click the button named ‘Settings’
  • Go to the ‘Templates’ tab
  • Create a new template named
  • Add the following in the template:

This template is based on the Apache Commons toStringBuilder, and will generate a consistent toString for you using Google Guava.

This (two) week(s) in Discobot (30-31.2011)

Each week, we work on the Discobot project, which goal it is to make Groovy run on Android. While that in itself isn’t the biggest problem, as you can read in our previous blog posts, making developing for Android using Groovy and making sure we are feature complete, well, let’s say it’s challenging.

Current efforts are twofold: one is developing a set of developer tools using Gradle, on which Marcin is focusing the most. On the other hand, we need some tools to make sure our version of Groovy works on Android, which is what I (Erik) am focusing on.

Screen-shot-2011-08-09-at-9.53.44-PM

As you can see in the screenshot above, our project is already capable of building the project and installing it on the emulator using the Gradle plugin. Also, the start of a demo application has been built, which will allow us to run all the tests packed with Groovy. For that, we have tweaked the build process of Groovy itself, so that it produces a jar which includes all the tests. This jar is used in the Discobot project. To figure out which tests are available, an Android Classpath Scanner is used. It uses a hack by inspecting the Dex files itself, but we are currently using that to scan for files which extend from GroovyTestCase, and run those. Once that is working, we’ll probably write a better UI around it.

Also, the Gradle plugin still needs some finishing touches to improve the overall user experience. Marcin is currently working on the last gradle task which will initialize the android project structure. It will call the android create project command-line tool from Android SDK, change the src directory structure of your project to obey Gradle conventions and create a ‘Hello World’ activity written in Groovy, so you can quickly get a simple working application to start out with!

We’ll try to update you again with more information next week!