Travis Continuous Integration Fails

My Travis builds worked nicely until I start to add a java/groovy Swing view or GUI to my projects. The gradle tests run and pass locally, but Travis throws a java.awt.HeadlessException as soon as it tried to run the test suite.

The Travis docs suggest using a tool called xvfb (X Virtual Framebuffer) to simulate a windowing system and run headless tests, but also warn “you need to tell your testing tool process” exactly how to use it.

The solution is simple: just add a few arguments to .travis.yml file. Mine looks like this:

language: java
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"
  - oraclejdk7
  - openjdk7
  - openjdk8


Nice 😉

Is GPars on My Groovy Classpath ?

Since i use sdkman to manage my Groovy and Gradle installs, was wondering what jars it gives me in my groovyConsole classpath.

This script reveals all:


def printClassPath(classLoader) { println "$classLoader" classLoader.getURLs().each {url-> println "- ${url.toString()}"}

if (classLoader.parent) { printClassPath(classLoader.parent) } }

printClassPath this.class.classLoader

and the results are here:
Screenshot 2016-03-14 09.27.00

Website Performance ? – Use Google Analytics !

How to see how a website is accessed ? Use Google Analytics !

Google keeps track of visitors to websites based on a visitor’s search terms. This ability to track such vital data can lead to improved sales and more responsive website designs. Tracking Basics Quickstart notes are here.

The Analytics begin with a snippet, a small piece of JavaScript code that you paste into your web pages. It activates Google Analytics tracking by inserting ga.js into the page.
It uses a unique tracking code Google assigns your website. That tracking code is inserted into the google-provided javascript.

The javascript code for the asynchronous syntax requires two calls to _gaq.push.

_gaq.push(['_setAccount', 'UA-XXXXX-X']);

The UA-XXX.. is replaced by your uniquely assigned value. Javascript code like this is inserted each page you wish to track.

Drag and Drop Visuals in your Interactive Dashboard – Gridster & D3.js

This is a treat for quicker mock ups !

Anmol Koul

Greetings Folks,

As part of my continued interactions with the open source stack, i came across a very nice library: Gridster.js. Gridster is a really cool and awesome JavaScript library that enables drag and drop as well as re-sizing features for your html placeholders (div’s).

I have had my fair share of experience with self service modules provided by various BI tools like Spotfire, Qlik, Tableau etc. The main aim of these modules as i inferred is to allow the business user to focus on the business aspects of visuals rather than on creating and designing the visuals.
At the same time, These self service modules reduce the dependency on IT as opposed to the traditional reporting structures where the businesses have to rely on IT for report generation.
And lastly, these modules allow faster time to insights as the dependency on the IT is reduced and the business (analyst)…

View original post 763 more words

List of Groovy Annotations

Don’t know where i found this list but have always wondered what annotations can we use when coding groovy scripts ? This list may not include more recent annotations – sorry.

Yeah, know you always wanted to understand groovy annotations but were afraid to ask, so just to give you the scoop, yo can watch this Paul King video where he explains how it all works – enjoy 🙂

Groovy AST Transforms
Groovy AST Transforms by Paul King

For those who don’t know, annotations are metadata tags we provide to the groovy compiler. These annotations are not directly turned into byte code, but more typically generate a small set of add-on logic to support specific stuff.

One typical annotation i use a lot is

@ToString class Fred{}

which asks the groovy compiler to produce extra code to create a toString() method for my class rather than hand-code one myself – cos i’m a lazy bugger like that ;-}

The list so far is :

// Abstract Syntax Tree
- in memory transform of your groovy script before bytecode generation
- it's a macro-like compiler hook allowing further mods to post-xlate /  pre-generate stage
- Code generation

- Class design

- Logging

- Safe Scripting

@TypeChecked - throws error if typo in var.s ane method names, bad return types, wrong type assigns -- allows fine-grained type inferences for DSLs or dynamics
@CompileStatic - generates same bytecode as javac w/same performance whe used with @TypeChecked

- Swing

- Dependencies

- Testing


Let me know if you find more annotations we can add to this list.

StackEdit.Io – A Live Mark-Down Editor


This is a sample markdown edited tool. It uses the live-console approach. It’s like an immediate WYSIWYG editor – quite interactive. And this editor has two features that are really keen :
1. Direct upload of document to wordpress
2. Dropbox backing store for persistent document retention.
3. Go to read more of the doc.s meself !

If you want to try it out and have a Dropbox account, please see this link: as it will give you a live taste of what this tool can do. Enjoy 🙂

Written with StackEdit.

A Groovy Way to Use an H2 In-Memory Database

The H2Project

This is a short sample Groovy class with some tests to try out the H2 in-memory database feature.

Just wanted to give you a starting point to try the H2 in-memory database. I’ve used the Groovy development language here to setup a set of methods. The whole class named H2 is constructed in the style of a java class with all it’s syntax. Ok, it’s not exactly a java program. For that you would need to add more syntax.

For this demo, i’ve tried to use the most common features of the H2 grammar.

Project Layout

This project is arranged in a folder structure that’s compatible with many build systems. In this demo, i’ve used the gradle build tool. Have also included a full gradle wrapper with required bits and pieces the code needs to work correctly. These are declared within the build.gradle script.

Folder Layout

  • * build.gradle – the script gradle uses in the build process
  • * – influences the gradle build tool
  • * License – what you can/cannot do with this project
  • * – this text file
  • * build/ – a folder of all the pieces constructed when you do a gradlew build command
  • * gradle/ – everything needed to make gradle run on your system without installing gradle; Gradle will self-install any missing jars, code, scripts, etc if your system is connected to the internet the first time you do a gradle build command
  • * src/
  • * /src/main/groovy/com/jnorthr/H2.groovy – the only bit of code with samples of what can be done when working with the H2 database
  • * /src/test/groovy/com/jnorthr/H2Tests.groovy – a series of self-testing methods to confirm the H2.groovy class is running correctly.

H2 Syntax

The H2 Grammar is described here :