Archive for the ‘Groovy’ Category

Groovy++ goes APL 2.0!

April 19, 2010 Leave a comment

Groovy++ goes APL 2.0!

This is obviously great news to Groovy/Groovy++ community.

Categories: Groovy Tags: ,

Multi-level ternary operator

March 24, 2010 Leave a comment

Love one. Can’t be easily debugged, probably .. But reads very nicely:

String getScmClass()
    ( this.@scmClass == 'svn' ) ? 'hudson.scm.SubversionSCM'  :
    ( this.@scmClass == 'git' ) ? 'hudson.plugins.git.GitSCM' :

Still, standard mapping is usually better – it allows to dump all known options:

Map    scmClasses = [ svn : 'hudson.scm.SubversionSCM',
                      git : 'hudson.plugins.git.GitSCM' ]
String getScmClass()
  def    scmClass = scmClasses[ this.@scmClass ]
  assert scmClass, "Unknown [${this.@scmClass}]. Known classes are ${scmClasses.keySet()}"
Categories: Groovy Tags: ,

Using Groovy++ with Maven – an update

March 22, 2010 2 comments

In his comment to “Using Groovy++ with Maven” Joern Schimmelpfeng has correctly pointed out about transitive dependencies that may be added to groovypp POM, eliminating the need to specify them explicitly.

He’s right! That’s what we have Maven dependencies mechanism for.

It is now fixed so you can use




Full examples:

Now it looks practically the same – what’s the difference then?

As previously, groovypp-all.jar contains all required libraries, repackaged in one jar:

In addition to groovy ("groovy", "org.codehaus.groovy" packages) and groovypp ("org.mbte.groovypp" package) it also contains antlr, asm, commons-cli and junit libraries, some of which are stored under modified package names to avoid collisions with libraries that may be available already in your project.

groovypp.jar is bound to all above libraries in separate jars, as declared by its <dependencies>.

Which one to choose then?

  • If your application has already declared <dependency> on either antlr or asm and you
       don’t like them packaged twice (note, even in this case – there are no collisions due to
       packages modified), then you can choose the groovypp version.
       It usually works better in IDEA project as it doesn’t recognize "groovypp-all" jar as
       Groovy and tries to search for it elsewhere.
       Note: sometimes you may need to add an explicit junit:4.7 dependency, otherwise
       Maven brings old 3.8.2 JUnit version lacking classes required for Groovy++ compilation.
       It can be seen in groovypp example above, see the diff of switching from "groovypp-all"
       to "groovypp".
  • If you just want to just use Groovy++ without dealing with JUnit versions and you
       experience no Groovy-related IDEA problems – you can use groovypp-all.
Categories: Groovy, Maven Tags: , , ,

Using Groovy++ with Maven

March 18, 2010 11 comments

Note, an update is available.

Groovy++ artifacts are now deployed in Maven repository at:


So you can compile your Groovy++ sources with Maven.
As in Groovy, where you pick up either groovy.jar or groovy-all.jar – you can do the same here:

  • Use groovy + groovypp + asm + antlr + commons-cli:

  • Use groovypp-all:

As you see, the second way is much simpler so I suggest you stick to “groovypp-all”. It’s the same as a longer version but with all required libraries packaged nicely in one bigger jar. 

Of course, you’ll need to instruct Maven about repository:




.. and configure GMaven plugin:


Full examples:

If you didn’t do so yet – you’re welcome to join a community to take part in Groovy++ discussions and be notified about new releases (@groovypp is available as well).

Also, you can follow Alex Tkachman who is Groovy++ inventor at @alextkachman and DZone.

Hashcode, Adler, CRC collisions in action!

February 17, 2010 2 comments

If you want to see String’s hashcode, CRC32 or Adler32 colliding (producing same results for different Strings) – run this Groovy script:


def checksum( String s, Class<? extends Checksum> c ) {
    Checksum cs = c.newInstance();
    cs.update( s.getBytes(), 0, s.size())

assert checksum( "", Adler32.class ) == 
       checksum( "", Adler32.class )
assert checksum( "", CRC32.class ) == 
       checksum( "", CRC32.class ) 
assert "".hashCode() == 

// A combination of two?

assert checksum( "/ongoing/pie/0.2/?N=D?N=A?N=A?N=A?D=A?S=A?M=A", Adler32.class ) == 
       checksum( "/ongoing/pie/0.2/?N=D?M=A?S=A?D=A?N=A?N=A?N=A", Adler32.class )
assert           "/ongoing/pie/0.2/?N=D?N=A?N=A?N=A?D=A?S=A?M=A".hashCode() == 

Those functions aren’t supposed to generate unique numbers, of course (that’s what we have strong hash functions for).

Just thought I’d like to publish some of those collisions ..

Categories: Groovy Tags: , , , ,

Groovy/Maven – Multiline Strings

July 21, 2009 Leave a comment

Groovy multiline Strings are always using “\n” as line terminator and sometimes this may be a problem but a simple replace() solves it:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns              = ""
         xmlns:xsi          = ""
         xsi:schemaLocation = "
""".replace( "\n", "\r\n" )

I had this issue when ran the above multi-line replacement today (yeah, I’d like all POMs to have this nice header) – some files that already had this header were still modified by the script as it replaced “\r\n” that were previously in a file by “\n” – that’s when I had to add the replace() call.

Just something to keep in mind.

Update: same issue happens in Maven when it passes a multiline plugin’s configuration to Mojo (like replacement content between <to> tags) – it joins the lines with “\n” as well. If they’re to be written to a file – s.replace( "\n", System.getProperty( "line.separator" )) is required. Note that in Groovy version (above) I did not use System.getProperty() and that’s because we want all POMs have “\r\n” line-endings regardless of OS the script is running on (but we’re mostly using Windows anyway).

Categories: Groovy, Maven Tags: , ,

File.eachFileRecurse() – speedup when filtering directories

July 18, 2009 6 comments

File.eachFileRecurse() is a wonderful GDK addition in Groovy. In fact, this function was exactly the reason why I’ve started to code Groovy one day. We’ve talked about how “Maven with branches” problem can be solved and came to conclusion the simplest way would be modifying all <groupId> with some script. That’s when I’ve recalled that Groovy has a nice recursive iteration function for all files (that I was shown once).

After using this lovely function to iterate over all POMs in our source tree (and we have lot’s of them, believe me) I’ve noticed the iteration goes into directories I’d rather not go into – “.svn”, “build” and “dist” (the last two are our Maven’s <outputDirectory> and <directory>). That seemed like quite some time that could be saved! Unfortunately, eachFileRecurse() has no way to stop the recursion in a folder in order not to go any deeper.

So I have re-wrote it a little:

 * File.eachFileRecurse( Closure ) improvement accepting a filtering closure, which will be passed each file and
 * each directory found.
 * If filtering closure returns "true" - recursion continues as usual.
 * If it returns "false" for file      - the file isn't passed to execution closure (second argument).
 * If it returns "false" for directory - recursion will skip it, this makes a powerful speedup when recursively
 *                                       iterating files while skeeping certain folders
private static void eachFileRecurse( File    dir, 
                                     Closure closure, 
                                     Closure filter = { return true } )
    for ( file in dir.listFiles())
        if ( file ))
            if ( file.isDirectory())
                eachFileRecurse( file, closure, filter );
       file );

Now, having the following filter ( this.skipDirectories is [‘.svn’, ‘build’, ‘dist’] in my case):

Closure recursionFilter =
    file –>
    if ( file.isFile())
        return ( == ‘pom.xml’ );

if ( file.isDirectory() && ( this.skipDirectories.any{ it == } )) { return false; }
return true; };

I’m now getting a 3-7 times speedup when iterating over sources tree! Skipping certain directories does matter 🙂
It reminds me of university days where we were solving a TSP problem as part of “Concurrent And Distributed Programming” course – the major speedup was always coming from skeeping certain paths.

Let’s now try to add this option to Groovy GDK.

Categories: Groovy Tags: