Powerful feature in Gretty 0.0.24 - full support of Spring Boot 1.1.0

Today is a wonderful day: Spring Boot 1.1.0 was released and I released Gretty version 0.0.24.

Gretty is a feature-rich gradle plugin for running web-apps on Jetty. It supports multiple Jetty versions (7, 8 and 9), multiple web-apps and many more. It wraps Jetty functions as convenient Gradle tasks and configuration DSL. A complete list of Gretty features is available in feature overview.

There is new powerful feature in Gretty 0.0.24: it supports running Spring Boot web-apps out-of-the-box. All Gretty features, including (but not limited to) debugging, code coverage and integration tests, also apply to spring-boot web-apps.

Simplest Gretty setup with Spring Boot:

You get Gretty as maven artifacts at jcenter and maven central under the group "org.akhikhl.gretty".

Full Gretty sources and examples are available at https://github.com/akhikhl/gretty

Full Gretty documentation is available at http://akhikhl.github.io/gretty-doc/  

Gretty version 0.0.15 is out!

I release Gretty (gradle plugin for jetty) version 0.0.15!

New: fast-reload of webapp-resources, jdk8-compatibility.

Sources and documentation at https://github.com/akhikhl/gretty.

Also available on jcenter & maven central!

gradle-onejar plugin version 0.0.5 is out!

I just released gradle-onejar plugin version 0.0.5!

The sources are available at https://github.com/akhikhl/gradle-onejar.

gradle-onejar is a gradle plugin, automating assembly of java application to a single runnable jar.

The plugin is available in maven central under coordinates “org.akhikhl.gradle-onejar:gradle-onejar:0.0.5″

It has many configuration options, described in online documentation.

Your comments and suggestions are welcome – here and at github!

Gretty version 0.0.9 is out! Long live gradle and jetty!

I released Gretty (gradle + jetty) version 0.0.9!

New: support of JEE annotations.

https://github.com/akhikhl/gretty

Also in maven central!

Gretty Plugin is now on Maven Central

I published Gretty Plugin to maven central, coordinates: org.akhikhl.gretty:gretty-plugin:0.0.4

Project home: https://github.com/akhikhl/gretty

scm: https://github.com/akhikhl/gretty.git, git@github.com:akhikhl/gretty.git

Gretty Plugin is actually gradle plugin for running web-applications under jetty 8.1.8 and servlet API 3.0.1.

groovy script for running jetty server

The following script starts jetty server and opens the folder, specified on command line, for http access (read-only):
Usage:

1. Save this script to file “jetty.groovy”
2. Invoke on command-line:
   groovy jetty.groovy /path/to/some/folder"
3. Enter address in web-browser:
   http://localhost:8080/jetty

Expected result: you see the content of the folder “/path/to/some/folder” in the web-browser.

groovy switch: nasty bug

I found nasty error in Groovy compiler. Consider the following code:

1 2 3 4 5 6 7 8

byte b = 1 switch(b) { case 0..9: println 'it is between 0 and 9' break default: println 'it is something else' }

It executes 'default' part, not the part with 0..9, which is not what a programmer would typically expect.
The reason behind it should be related to type conversion between "byte" and "int" types. With the following workaround:

1	swtch((int)b)

the program executes "proper" case.

groovy: switch statement and closure comprehension – nice for DSL

It is rather easy to extend groovy switch statement with our own DSL:


The trick here is that single-argument versions of IsGreaterThan, IsLessThan return closures. Switch-statement “understands” closures: it passes it’s argument (x in our case) as a parameter to the closure and expects boolean result being returned from the closure.Same thing can be done via function currying, but it looks not so nice, as with function overload.

Groovy language, spaceship operator

x <=> y

Useful in comparisons, returns -1 if left is smaller 0 if == to right or 1 if greater than the right.

Isn’t it sweet?

Groovy DSL == thermonuclear way of writing XML

The code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

import groovy.xml.MarkupBuilder String createEAD(Closure closure) { def writer = new StringWriter() def xml = new MarkupBuilder(writer) xml.mkp.xmlDeclaration(version: '1.0', encoding: 'UTF-8') xml.'ead:ead'('xmlns:ead': 'urn:isbn:1-931666-22-9') { closure.delegate = new Object() { def text(Map attrs, content) { def a = attrs.keySet().find { it in ['bold', 'italic', 'underline'] } if(a && attrs[a]) { xml.'ead:emph' render: a, { text attrs.findAll({ it.key != a }), content } } else text content } def text(content) { if(content instanceof String) xml.mkp.yield content else if(content instanceof Closure) content() } } closure() } return writer.toString() } println createEAD { text bold: true, italic: true, { text 'Hello, ' text underline: true, 'world!' } }

produces XML:

1 2 3 4 5 6 7 8

<?xml version='1.0' encoding='UTF-8'?> <ead:ead xmlns:ead='urn:isbn:1-931666-22-9'> <ead:emph render='bold'> <ead:emph render='italic'>Hello, <ead:emph render='underline'>world!</ead:emph> </ead:emph> </ead:emph> </ead:ead>

Partial interface implementation in groovy

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

interface X { void a() void b() } class XAdapter implements X { void a() { println 'default implementation of a' } void b() { println 'default implementation of b' } } def o = [ a: { println 'overridden implementation of a' } ] as XAdapter o.a() o.b()

will output:
overridden implementation of a
default implementation of b

Copy very large files with groovy

The following one-liner can copy very large files without running out of memory:

1	new File("test").withInputStream { new File("test2") << it }

Just tested it in groovy console - 1 GB file is copied in 5 seconds, memory consumption stays low.
The copy is binary, i.e. it copies bytes, not chars.
One particularity: left-shift operator rather appends than overwrites. If you need to overwrite the file, first need to delete it.

Fun with groovy maps and function call syntax

A function having a Map as first parameter:

1 2 3 4

void doIt(Map attrs, Object content) { println attrs println content }

supports equally valid call syntax variations:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// "classical" call syntax, known from java world doIt([color: 'red', type: 'fruit'], 'hello!') // parentheses can be omitted doIt [color: 'red', type: 'fruit'], 'hello!' // even square brackets for map can be omitted doIt color: 'red', type: 'fruit', 'hello!' // order of map properties does not matter, // map properties can be intermixed with unnamed parameters. doIt color: 'red', 'hello!', type: 'fruit' doIt 'hello!', type: 'fruit', color: 'red'

this effectively allows to implement named parameters in groovy.

Power of switch statement in groovy

Very impressive (and expressive):

def x = 'test'

switch(x) {
  case null:
    println 'null!'
    break
  case ~/(?i)Test/:
    println 'got it!'
    break
  default:
    println 'something else'
}

here second 'case' does case-insensitive regex comparison. In general, case may contain any regex, collection, range or class.

Change in JDK 1.7.0_25 breaks all grails applications:

https://bugzilla.redhat.com/show_bug.cgi?id=976693 

I just tried grails 2.2.3 - the problem is still not fixed, the application fails to start with an error message "Could not determine Hibernate dialect for database name [H2]".

Any workarounds suggesting to replace hibernate libraries don't work.

The following additional parameter allows to start grails:

grails -noreloading run-app

But hey, it's no fun to start in no-reloading mode! Oracle, but things back!

A happier, groovier way to parse RTF: apache_tika + XmlSlurper

I discovered a new way to parse RTF in java/groovy programs.

Consider the following sequence:

1. Instantiate XmlSlurper
2. Instantiate RTFParser (of Apache Tika)
3. Parse RTF (either file or string), passing XmlSlurper to RTFParser (such passing is possible, since RTFParser expects ContentHandler interface, which is implemented by XmlSlurper).
4. Traverse RTF content groovy-style: each, find, findAll, etc.

Example of code here:
https://gist.github.com/akhikhl/5993538

Disappointment with groovy/XmlSlurper

Greatest disappointment with groovy/XmlSlurper: it does not read/interpret XML comments. Quite critical for massive XML processing/transformations, when it is necessary to keep change delta to minimum.
In the last project I had to recede to JDOM2 - it reads, interprets and writes XML comments without problems. Sad, volume of code doubles compared to XmlSlurper.

groovy XmlParser and XmlSlurper

I am absolutely astonished by functionality of groovy classes XmlParser and XmlSlurper. The both are similar to each other, with one important difference: XmlParser is more DOM-like (all data in memory), while XmlSlurper is more SAX-like (data parsing delayed until needed).

The most charming thing is how both work together with closures, regexps and collection methods. I am seriously thinking about shifting all XML-specific code to these facilities.

http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlParser 
http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlSlurper

gradle snippet: sources and javadoc jar for every subproject of given project