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
@ToString
@EqualsAndHashCode
@Canonical
@TupleConstructor
@InheritConstructors
@Category
@IndexedProperty
@Lazy
@Newify

- Class design
@Delegate
@Immutable
@Memoized
@Singleton
@Mixin

- Logging
@Log
@log4j
@Log4j2
@Slf4j

- Safe Scripting
@ConditionalInterrupt
@ThreadInterrupt
@TimedInterrupt

-CompilerDirective
@Field
@PackageScope
@AnnotationCollector
@DelegatesTo
@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
@CompileDynamic

- Swing
@Bindable
@ListenerList
@Vetoable

- Dependencies
@Grab
@GrabConfig
@GrabExclude
@GrabResolver

- Testing
@NotYetImplemented
@ASTTest

More

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

StackEdit.Io – A Live Mark-Down Editor

StackEdit.IO

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: https://stackedit.io/editor# 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

https://github.com/jnorthr/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
  • * gradle.properties – influences the gradle build tool
  • * License – what you can/cannot do with this project
  • * README.md – 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 : http://www.h2database.com/html/grammar.html

README2.md

Groovy Koans Project

The Groovy Koans project is a collection of small exercises in the form of unit tests, designed to get Java developers up to speed on Groovy features and common idioms. It starts by teaching you basic Groovy building blocks, and gradually builds your knowledge towards metaprogramming, slurpers, and all the goodness Groovy has to offer !

Getting Started

  1. Make sure you have JDK 1.6+ installed
  2. Download and unzip the Koans (or clone the GitHub repository with $ git clone https://github.com/nadavc/groovykoans.git)
  3. Remove the solutions from the Koans using $ ./gradlew removeSolutions
  4. Execute Koan01 with $ ./gradlew koan01 and fail (or any other Koan using $ ./gradlew koan##)
  5. Fix code, and execute again
  6. Keep going until you’re fluent at Groovy :)

Q&A

I like IntelliJ. How can I use it to debug/edit the Koans?

I am forced to work behind a proxy. Can I still run the Koans?

The gradlew script downloads Groovy and Gradle for you, so you don’t have to set up anything by yourself.
To allow gradlew to work through your proxy, simply add the following parameters:

$ ./gradlew koan01 -Dhttp.proxyHost=[http proxy] -Dhttp.proxyPort=[http proxy port]

The answers are already there! What’s the point?

One of the perks of learning through Koans is that once your Koan is solved, you can compare your solution with
the ‘official’ solution and perhaps learn from that comparison as well. It is also a way to make sure that the Koans
are indeed solvable by filling in the blanks.

For optimal learning experience, however, you should first try to solve the Koans without those solutions as reference.
To remove the solutions, run $ ./gradlew removeSolutions from the root of your unzipped Koans.

Are there more Koans planned? How will I know?

These are the Koans that are currently planned:
* Embedding Groovy
* Creating your own DSL
* Creating your own builder
* Transformations
* GPars

Follow me on Twitter or GitHub for updates.

Credits and License

The Koan concept started way back in Zen practice. It was then adapted by the good folks of
rubykoans.com and perfected by Neo4j. The Groovy Koans project is licensed under the
WTFPL.

Please feel free to leave comments and pull requests :)

Enjoy!

How Gradle Makes Windows and *nix App Deploy Scripts

Thanx to Mk Yong for this idea: http://www.mkyong.com/gradle/gradle-create-a-jar-file-with-dependencies/

Assets for this post are held here: https://github.com/jnorthr/gradleMakeWindowsBat.git


 

Here is a skeleton gradle project template to build an executable java jar plus all distributable assets for a ‘HelloWorld’ java source. This is to deploy your app as a stand-alone app on a client system, something like a GUI, or batch job app – NOT a web service.

The tasks to do this are a freebie when a build.gradle file includes a plugin module named ‘application‘ courtesy of

> apply plugin:’application’

Gradle Build Tool

This project includes a full gradle build tool as a ‘wrapper’ bit inside this download. So there’s no need install gradle on your system. You can run this app once you’ve done a git clone.

Git Source Code Control

Yes, you need Git installed on your system to get started. So change into a new folder/directory on your local system and do this:

git clone https://github.com/jnorthr/gradleMakeWindowsBat.git

This makes a project directory folder named gradleMakeWindowsBat so cd into that.

You could use this approach as a foundation to create several brand-new projects. Sure you would need to change gradleMakeWindowsBat to something else and the main class names would change too, but a lot of the setup work is done for you here.

Build / Check

Now you can just run the gradle wrapper like so:

> gradlew check

or

> bash ./gradlew check

This will ask gradle to download any dependency bits it needs to make it happy, and check that everything is cool on your installed version.

Build

Ok, to make it all happen, run gradlew again without options.

> gradlew

or

> bash ./gradlew

The default tasks are run. These are:

defaultTasks ‘clean’, ‘build’, ‘javadoc’, ‘installApp’, ‘startScripts’, ‘fatJar’, ‘distTar’, ‘distZip’, ‘run’

Tasks to Deploy An App

clean – gradle cleans the environment before starting

– build – when javac – compiles the HelloWorld module

javadoc – the javadoc API document is created with any source code comments

– installApp makes a folder named install and a sub-folder of gradleMakeWindowsBat containing /bin, /docs, /lib folders with all the pieces to do a full install on a client system. Ship the gradleMakeWindowsBat folder and change the client’s OS path variable to include gradleMakeWindowsBat/bin then on the command line you/they can run this job by typing the name of this  batch script file as gradleMakeWindowsBat  – easy-peasy !

startScripts – makes a folder of identical windoze and unix batch script files. These scripts will run the core job noted in the build.gradle file as

mainClassName = "com.jnorthr.DateUtils"

– yeah, you can change that for your own needs. Be sure to add the .jar files in build/libs to the system CLASSPATH variable.

fatJar – my favorite ! makes an executable jar file of the java/groovy/scala/jvm language classes and bits. You can just double click on the gradleMakeWindowsBat-all-1.0.jar file to run your app.

Alternatively from a command line with the jar in the same folder, you can do this:

> java -jar gradleMakeWindowsBat-all-1.0.jar

Everything needed has been included in this ‘fat’ jar !


Tasks to Transfer The Project Build Environment

When we need to move/copy/transfer a complete project that includes all the development tools, build stuff and source code controls, we can use either of these two tasks depending on the target computer system’s OS:

distTar packages up the full folder directory and makes it ready for shipment to a target computer system running Unix/Linux/Ubuntu etc.

– distZip packages up the full project folder directory in a compressed archive format. This is useful as a general-purpose tool to move a complete project around to target computer systems where the OS is unconventional like, say, Windows, IBM, DEC.

Both tasks run as a default set of tasks. Project build times may seem excessive as so many solutions are being produced. To speed things up you could alter the build.gradle file to remove these two tasks if you do not plan to move the project to another system.

Task to Run This App

– the run task starts execution of an app. The app name is declared in the build.gradle file as

> mainClassName = "com.jnorthr.DateUtils"

change to suit your own requirements.