Added support to Groovy Compiler to allow source files with extensions of your choice

I am happy to finally push the change to groovy compiler so it allows users to mix and match the groovy source with multiple extensions of their choice –

For example, Groovy++ has *.gpp and *.grunit files. You may want to have *.g or *.gscript, or *.gdsl or *.gspec, or whatever else – and have a mix of any number of them.

The feature is currently available in 1.7.5 and 1.8.0-beta-2 snapshots, which are available from here –

All that needs to be done to use this feature is to have your extensions listed down in the file META-INF/services/org.codehaus.groovy.source.Extensions and make it available on the classpath and the groovy compiler will do the rest.

Here is a sample of how the file may look like:

# Format: one extension on each line without the leading “*.”

Feedback welcome.

Tools/Technologies that make it Groovy.

I thought I will write a bit about what tools/technologies are there internally used in Groovy. So, here are the more prominent ones – in no particular order:

  • Jansi – It is a java library that used to give groovy shell command line a consistent look and feel and behavior across operating systems. It handles the ANSI escape sequences to control the output on console terminals.
  • Commons CLI – Apache Commons library to process command line options. Groovy makes its usage nicer and easier by providing a CliBuilder on top of it.
  • Apache Ivy – Dependency manager framework behind the groovy feature @Grab (Grape) that allows you to mention in a script what libraries it requires and then transitively fetches them from a central repo like maven repo.
  • Retrotranslator – It makes your java 5+ application compatible with JDK 1.4 (and lower) – through bytecode manipulations. Until Groovy 1.6, groovy runs on JDK 1.6/1.5/1.4 even though its own Java code is written in JDK 1.5. For groovy on JDK 1.4 environments, groovy code gets retro-translated using this library.
  • bnd – It is used to turn groovy-*.jar and groovy-all-*.jar into OSGi compliant bundles
  • JarJar – It embeds all the basic libraries needed by groovy at runtime into its fat groovy-all version so that this fat version needs no external libraries at runtime and avoids version conflict.
  • Maven – If you are setting up development environment for groovy, there are a lot of libraries it depends on – for compile time, runtime, etc. Maven is used to manage these dependencies.
  • Ant / Gradle – The build system of groovy is currently in transition from Ant to Gradle – soon, it should be all Gradle based, which itself is written in Groovy.
  • ANTLR – Groovy grammar is defined using ANTLR syntax. Groovy source parser is generated by ANTLR.
  • ASM – It’s the bytecode manipulation library that groovy uses to generate JVM compliant classes

There are many more useful things done in Groovy projects. More to come.

Started Bangalore Groovy Users Group (BUG)

I just created a new google group for Bangalore Groovy Users –

I really wanted to get in touch with some really interested in technologies around Groovy. I hope some like-minded people will join and we will be able to build an locally active Groovy community in Bangalore and make the world a groovier place.

Bangalore DevCamp UnConference 2010

Attended Bangalore DevCamp 2010 at ThoughtWorks office today. Quite decent – lots of interest in scripting and functional languages seemed to be there.

There were two talks on Clojure, one on Groovy and one on using functional programming approaches in OO languages. And I barely made through one heavily mathematical talk “Machine Learning and Compilers” by Ravi Mohan

Day well spent and a nice T-shirt to show off too!🙂

Relationship between Groovy and Groovy++ projects (integration feasibility and roadmap)

What exactly is the relationship of Groovy++ with Groovy project is a question that seemed to be causing a great deal of confusion in groovy users. Every other day someone would ask on one mailing list or the other “yes, we like what Groovy++ provides but, was Groovy++ going to get merged into Groovy, or did it intend to directly compete with Groovy, etc” and then the unplanned (and sometimes heated) discussions on the mailing lists would start and that didn’t really help the matters.

So, Alex Tkachman, the manager of Groovy++ has taken the initiative to clarify where Groovy++ stands in relation to core Groovy, what it currently offers over it, where it deviates and how soon he expects it to stably integrate with core Groovy. Here is a link to the discussion on Groovy/Groovy++ marriage roadmap with the core teams of both the projects involved:

I hope it will present a clear and consistent picture to the users of groovy ecosystem.

A Utility Tag-Cloud App on Google App Engine

Here is another utility application I have put on Google App Engine – I wanted to check out how persistence and security works in an application developed for App Engine. Another thing I wanted to check out was how tag clouds are implemented.

This utility allows you to enter items, categorize them and then label them with tags you want to remember those items with. For example, if you want to maintain information about the movies you know, the books you have read, you can create categories called Movies, Books, and then start adding information under books and movies of your interest and easily navigate through the popular ones using the tag clouds that get built up.

Here is the accompanying article I wrote on DZone discussing its technical details.