May 03

Scripting Maven with Groovy

Builds, Groovy, Java, Tech 2 Comments »

Imagine Maven talking to Jelly talking to Ant talking to Groovy :)

Jeremy Rayner contributed a nice Groovy Ant task, which we can piggy back on in Maven.

Guillaume Laforge put in the magic to make sure that the Maven POM is injected into the scripting engine, so you can play with $pom:

<project default="groovy" xmlns:ant="jelly:ant">
<goal name="groovy">
<ant:taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="maven.dependency.classpath"/>
println pom.eachPropertyName{ println it }

It would be cool to be able to <ant:groovy script=”….”/>, or to write tags IN Groovy itself.

Of course, with m2 we will be able to write plugins with Groovy (as well as BeanShell and the like).

Brett Porter also talked about his addition to Maven to support CVS/SVN as a Maven repository itself. I personally am fine with using a traditional repository, where the http://….. is a SVN view itself, but I do hear people asking for exactly what Brett has implemented. Kudos Brett for doing this even though you won’t be using it yourself!

Apr 22

Groovy Lucene

Groovy, Java, Search, Tech 4 Comments »

Lucene is one of my favourite opensource packages. I often find that I do need to ’script’ it so to speak, and Jeremy Rayner has shown how Groovy fits in.

He has taken some examples from Lucene in Action, and made them Groovy.

Very nice.

Apr 06

Groovy JSR Hyperlinked Grammar

Groovy, Tech No Comments »

I am going through a slew of Groovy code and making sure it works in Groovy JSR.

From time to time it is nice to look at the grammar to see what is happening, and there is a hyperlinked version at:

My observations on the migration so far are:

  • Get ready to do a s/// for: |\s*(\w+)\s*| to the -> version
  • I am a fan of ‘#’ for comments, so I had to s|#|//|
  • Get ready to do some ‘def’ additions although…
  • I was surprised when a lot of scripts ‘just worked’ after the || conversion. I was surprised because I knew I wasn’t ‘def’ing all of my variables. It turns out that the current parser is fairly lax (apart from with member variables and methods), so I all of the following just works:
    aVar = "aVar"
    println aVar
    def m() {
    println aVar
    anotherVar = "anotherVar"
    println anotherVar
    class Foo {
    def f = "letter f"
    def printF() {
    println this.f
    def printG() {
    g = "letter g"
    println g
    fc = new Foo()

    The parser will get stricter though, so I will have to do def additions (I understand why, but I prefer not having the noise)

  • I spent some time breaking things to see what errors came out. For the first time ever, I actually was pointed to where the problem was (with the correct line in script). Now I just wish they could surpress the huge stacktrace that occurs and just tell me the problem. Let me give a -option to see all of the evil crap.
  • I know that I haven’t hit the hard snags yet though…. so we will see!
Apr 06

Groovy 1.0 JSR 1 Released

Groovy, Tech 1 Comment »

James and co. have released the first JSR based Groovy: groovy-1.0-jsr-01.

Now is the time to go through a bit of pain ;) and migrate old groovy scripts over.

Notable Changes

  • Introduction of a def keyword
  • Parameter separator in the closure syntax
  • Safe navigation
  • Property keyword
  • Array creation
  • float and double notation
  • Explicit method pointer syntax
  • No ‘do
Mar 31

Perl Deja Vu with new Groovy Syntax

Groovy, Tech 4 Comments »

One of the nice things about playing with Groovy is that I get some deja vu now and then, back to my Perl and Python days.

For instance, Jeremy Rayner showed us that a Classic Groovy trick is here in JSR Groovy:

Rather than the boring, repetitive:

Point p = new Point(2,5)

you can now do

Point p = [2,5]

This is because groovy will try to do a coercion of a List into the right type needed for the assignment.

It uses the list to choose the appropriate constructor, then invokes it for you. neat.

This then has the effect in most places, such as setters (e.g. for a property of type Point)

foo.point = [2,5]

and in named parameters

bar.setPointLimits(upper:[7,9], lower:[2,4])

And the really interesting stuff (to me) is that the empty list is coerced into the default constructor.

Date today = []
println "the time at the moment is $today"

is equivalent to

Date today = new Date()

I am not sure how much of a fan I am of taking the list syntax ([ ]) and making it have sideeffects, especially [] == empty constructor, but it does remind me of a pattern that was used a lot in the Perl days.

We used to fake named params by passing in Hashes, or references to Hashes a la:

do_foo(a => “hi”, b => 32)

So, I would love to see some syntax to enable me to pass named params in a simple syntax.

Something like:

Point p = [x:1, y:2]

foo.point = [x:1, y:2]

Of if you don’t want to hijack the syntax, you can do with a suggestion from John Rose:

Date d = (77, Calendar.JUNE, 28)


Date d = (year:77, month:Calendar.JUNE, day:28)

Basically we are getting rid of the implicit new Foo(), and making an assumption from the type that we set. This is funny, as we have been getting rid of the implicit type all along (and potentially even in C# 3.0 [and therefore Java 7? :)]):

d = new Date(77, Calendar.JUNE, 28)

There are different cases. One for when you are passing in new objects to methods, and the other when you are creating a new object. Also there are the sideeffects of “I want to tell you this type”. Worth exploring… not sure how I feel about it all yet!

Mar 16

Coyote: Dynamic language support in NetBeans

Groovy, IDE, Java, Tech 1 Comment »

It was great to hear about Coyote:

The goal of this project is to develop a set of NetBeans modules to help developers write code in dynamic languages using the NetBeans IDE. Initially, we are targeting the the Groovy and Jython languages, but we anticipate a common framework allowing support for more languages.

The coyote is a quiet, efficient animal that thrives in urban and rural settings without any particular encouragement, and once established in an ecosystem, is virtually impossible to eradicate.

Getting completion and the like for Groovy is a god-send. This will have me installing NetBeans just for that development, although coyote doesn’t support 4.1 beta (which is actually VERY slick).

I wish this was in IDEA and Eclipse ;)

Mar 15

Java is boring

Groovy, Java, Ruby, Tech 24 Comments »

Tim Bray has taken a look back at his first year at Sun, and claims that Java is boring.

He isn’t trying to start a flame war.

Java isn’t boring for many people, and that is fine. It is also a good choice, as he claims, for many tasks.

However, I have to agree with him. PERSONALLY I find Java a little boring. Sorry. Coding in it is boring (I know, I know, if the problem is interesting then who cares about the environment? I do).

I can’t state how many guys who use Java for most of their day job say to me:

“Man, I wish I could get a paying job with Ruby”

These people are playing with Ruby in their spare time. Then they get to do a prototype in it, and then it spreads from there.

Although Java the LANGUAGE is boring, that doesn’t mean the platform is.

I hope that 2005 is the year of more expression in many languages on the JVM. Come on Sun, get in the game. Get more people hacking away on languages like Groovy to see where it takes us. Where is the Sun version of Comega?

Boring Isn

Mar 02

Learning from others about semi-colons :)

Groovy, Tech 3 Comments »

Mark Igra is looking to others to help make decisions and learn:

The term semicolon insertion informally refers to the ability to write programs while omitting semicolons between statements. In both ECMAScript 3 and ECMAScript 4 there are two kinds of semicolon insertion:

Grammatical Semicolon Insertion
Semicolons before a closing } and the end of the program are optional in both ECMAScript 3 and 2.0. In addition, the ECMAScript 4 parser allows semicolons to be omitted before the else of an if-else statement and before the while of a do-while statement.

Line-Break Semicolon Insertion
If the first through the nth tokens of an ECMAScript program form are grammatically valid but the first through the n+1st tokens are not and there is a line break between the nth tokens and the n+1st tokens, then the parser tries to parse the program again after inserting a VirtualSemicolon token between the nth and the n+1st tokens.

Grammatical semicolon insertion is implemented directly by the syntactic grammar’s productions, which simply do not require a semicolon in the aforementioned cases. Line breaks in the source code are not relevant to grammatical semicolon insertion.

Line-break semicolon insertion cannot be easily implemented in the syntactic grammar. This kind of semicolon insertion turns a syntactically incorrect program into a correct program and relies on line breaks in the source code.

After working in languages that don’t require;
putting semi colons;
at the end;
It is nice to have the option to not have too;

As long as:

a) it is implementable
b) it doesn’t cause other horrible things to happen in the language just to make it implementable.

NOTE: I can understand reasons why you may like semi colons (history, java, periods in language). This is one of those personal feel things for me.

Feb 22

Even cleaner Map, List, and Array support

Groovy, Tech 12 Comments »

One of my minor pet peeves with Groovy has been:

# simple list
def x = [1, 2, "three"]

# another type of list
def x = new LinkedList()
x << 1

And it is also annoying to have a different way to setup a Java Array:

int x = new int[] { …. }

Why not unify this? Groovy is good about consistency, and trying to unify the models, so now maybe we will get there via:

def x = [1, 2, 3] as LinkedList

def x = [1, 2, 3] as int[]

def aMap = ['name':'value', 'n2':'val2'] as TreeMap

Much cleaner!

Emmanuel Pirsch also had a good idea of using casting:

int[] x= [1, 2, 3]

x= (int[]) [1, 2, 3]

x= (TreeMap) ["name" : name, "value" : value]

Jan 14

Groovy: Using corporate backing, versus becoming a corporations project

Groovy, Tech No Comments »

I feel like I need to clarify what I meant by having a Sun/BEA/Google/whoever taking part in Groovy.

I don’t want a big corporation to come in and take over and make it a marketing exersize.

What I really want is:

Full time leader(s) to push the language, show their passion, and move it along!

If someone stepped up to the plate to do this in their spare time, more power to them! The problem is that time is a tough commodity, so if a company could come in, see the value in Groovy, and allow for this leader to put all of their effort into the course, it will only be a good thing :)

Groovy needs strong leadership, direction, and to pick up momentum again…. much more so than a commitee. I worry about the JSR process since:

a) Design by commitee
b) Most importantly, what are we trying to standardize? Let’s get a kick arse implementation first, and *maybe* standardize later. Groovy currently fails the rule: “Never standardize a 1.0″

Although some people think that the JSR will give Groovy more of a chance in the corporate world… I don’t think it matters that much, and DEFINITELY doesn’t matter if we never get to a top notch implementation.