Introducing gradle-syntastic-plugin 0.3.6

I’m excited about this release of gradle-syntastic-plugin becauase it make integrating syntastic with your Gradle projects simple. The secret is getting it to work with the Gradle Plugins mechanism. Now the only thing required to setup a project is to add the following to your plugin DSL.

id "com.scuilion.syntastic" version "0.3.6"

Here is an example of what a simple Java project would look like in Gradle.

plugins {
    id "org.gradle.java"
    id "com.scuilion.syntastic" version "0.3.6"
}

Before this release it was a requirement to include jcenter in the repository block and add the dependencies to the buildscript classpath, but no more.

The library is still published on bintray so if you need to use the old style it is still supported.

Release Notes: https://github.com/Scuilion/gradle-syntastic-plugin/releases/tag/v0.3.6
Example Usage Project: https://github.com/Scuilion/documenter/blob/master/build.gradle

First Experience with Bintray

When I started to learn Gradle, I wrote a simple plugin. It was a fairly useless adapter for JavaExec. It automatically set up the classpath and created an extension for pointing to the main class. This was a exercise.

project.extensions.create("runSimple", RunSimpleExtension)

project.task('runSimple', type: JavaExec ) {
    project.afterEvaluate{
        main = project.runSimple.mainClass
        classpath = project.sourceSets.main.runtimeClasspath
    }
}

Recently, I’ve been beefing up my development process in Vim and installed Syntastic. This plugin provides syntax checking by running external checkers, two of which I needed–JSHint and javac. Out-of-the-box, Syntastic works great with Java, until you start adding external libraries. Fortunately, I use Gradle on all of my projects and Gradle makes it easy to determine you dependencies.

project.sourceSets.each { srcSet ->
    srcSet.java.srcDirs.each { dir ->
        classpathFiles.add(dir.absolutePath)
    }
}

So I added this functionality to my original plugin and called it gradle-utils. The problem was the hassle of using the plugin from one computer to the next. I’d have to pull the project from GitHub and publish it locally (using the maven-publish plugin). Not to mention if I made changes the whole process would start over.

In Walks jCenter

This was a perfect opportunity to try out BinTray. I’d had an account, but other than signing up, it sat dormant. Here are a list of the things learned while uploading my first artifact.

  • Don’t forget you have to push up your source as well as the complied classes if you want to attach you package to the public jCenter repo. I’m using the gradle maven-publish plugin and accomplish that like so:
    task sourceJar(type: Jar) {
        from sourceSets.main.groovy
        from sourceSets.main.resources
    }
    artifacts {
        archives jar, sourceJar
    }
    publishing {
        publications {
            maven(MavenPublication) {
                from components.java
                artifact sourceJar {
                    classifier "sources"
                }
            }
        }
    }
    
  • Gradle 2.1’s new developer plugin index makes include the Bintray plugin a snap. (Example of this below.)
  • In order to include your package in the the publicly accessible jCenter you have to ask. It took me longer than I would like to admit to find how to do this. I assumed that the option would be located somewhere within the package you were attempting to release, but it actually on the home page of jCenterbintray

A Personal Plugin for Personal Use

This plugin is very “me” centric, but it’s really easy to get it setup, assuming you already have the Syntastic plugin working in Vim. There are two things you need, 1) set Syntastic so that it creates a config file, and 2) add the gradle-utils plugin to your build.gradle file.

1) .vimrc

let g:syntastic_java_checkers=['checkstyle', 'javac']
let g:syntastic_java_javac_config_file_enabled = 1

2) build.gradle

buildscript {
    repositories {
      jcenter()
    }
    dependencies {
       classpath group: 'com.scuilion.gradle', name: 'utils', version: '0.2'
    }
}
apply plugin: 'utils'

Note: This is a post process plugin and should be applied at the end of your build file.

Screenshot from 2014-07-19 17:18:02
When junit is commented out of the build file, Syntastic shows that it can’t compile this particular file.

An aside: I used Gradle 2.1’s developer index to include the BinTray plugin. So instead of:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:0.5"
    }
}
apply plugin: "com.jfrog.bintray"
plugins {
    id "com.jfrog.bintray" version "0.5"
}

Pretty cool!

NERDTree and CtrlP in Vim

Finally carved some time out to tweak how I navigate code in Vim. I’ve had NERDTree installed but because I didn’t spend the time to learn the navigation keys, I ended up falling back on my old method for navigation. After learning the keys I set up a quick way of loading up the tree view (noremap \\ :NERDTreeToggle), and set all my bookmarks and show them by default(let NERDTreeShowBookmarks=1).

CtrlP is a great plugin for when you know your code base. I added a map key to reduce typing (let g:ctrlp_map = '<c-p>') and defaulted to name search instead of path(let g:ctrlp_by_filename = 1).

Integrating these two are where I find the most usefulness. I work with a bunch of branches, some in git and most in accurev. One of the projects I work on is actually buried down in the project structured. Because I have different configurations for projects the “root marker” features of CtrlP is not the best solution. But by having NERDTree change CWD whenever the root tree is changed (let NERDTreeChDirMode=2) and setting CtrlP to search under the current CWD (let g:ctrlp_working_path_mode = 'a'), then all I have to do when starting work on a certain project is to change my working directory (C hotkey in NERDTree or just selecting a bookmark) and CtrlP will automatically search in that project.

(Now I just need to get vim to automatically update saved files to my deployment area.)

.vimrc snippet for CtrlP:

"for CtrlP
let g:ctrlp_map = '&lt;c-p&gt;'
let g:ctrlp_cmd = 'CtrlP'
set wildignore+=*\\tmp\\*,*.swp,*.zip,*.exe,*.class,*.jar,*.html,*.xml
let g:ctrlp_root_markers = ['.acignore', '.gitignore']
let g:ctrlp_working_path_mode = 'a'
let g:ctrlp_by_filename = 1

.vimrc snippet for NERDTree:

" NERDTtree
let NERDTreeBookmarksFile=expand("$HOME/.vim-NERDTreeBookmarks")
let NERDTreeShowBookmarks=1
let NERDTreeChDirMode=2
noremap \\ :NERDTreeToggle

Groovy Syntax Highlight Update for Vim

The Groovy syntax highlighting that come with the Vim installation has a few thing that I don’t care for. As I transition more away from Eclipse as my main development environment, I’ll spend more time trying to get Vim setup to support more efficient development. Below I’ve enumerated what changes I made to the syntax file and why.

The TODO:

Bold, yellow highlighting of TODO and FIXME tags. I’m not a big fan of blaring reminders. It’s also not good to rely on just stumbling on a TODO as a way of indicating work to be done. If you really going “todo” it, go ahead and make sure you do more than make a tag for the next sap to come along. He might not have TODO and FIXME highlighted in his editor and might not notice your rushed programming.

Why Should def Be Any Different:

“def” is a type in Groovy; Similar to Integer, int, String, Array, etc. The word didn’t come up as highlighted and was getting lost when I would skim code.

Important Variable Obscured by Greedy RexEx

The match regex used for matching import statements was too greedy. It would highlight parts of the variables that had the word, import, in the name (e.g. importFileFromURL or someimportantmethod).

“””GStrings Deserve the Same Respect as String”””

The most common use in my code for GStrings is when I am lazily slapping xml into a test and want to be able to still read it and add variable replacement. The original Syntax file was only recognizing the first line of a GString.

The regex for matching import statements was taken from a Java syntax file. The GString update was from Tobias Rapp version 0.1.11 of the Groovy syntax file. I’ll maintain my version of the file on github with the caveat that some of the changes are skewed to my preferences and that I might add more. Hopefully, the README file will be kept up-to-date.