Archive
Groovy++ goes APL 2.0!
This is obviously great news to Groovy/Groovy++ community.
Multi-level ternary operator
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' :
null
}
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()}"
scmClass
}
Using Groovy++ with Maven – an update
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
<dependency>
<groupid>org.mbte.groovypp</groupid>
<artifactid>groovypp-all</artifactid>
<version>0.2.0</version>
</dependency>
or
<dependency>
<groupid>org.mbte.groovypp</groupid>
<artifactid>groovypp</artifactid>
<version>0.2.0</version>
</dependency>
Full examples:
groovypp-allversiongroovyppversion
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 eitherantlrorasmand you
don’t like them packaged twice (note, even in this case – there are no collisions due to
packages modified), then you can choose thegroovyppversion.
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 explicitjunit:4.7dependency, otherwise
Maven brings old 3.8.2 JUnit version lacking classes required for Groovy++ compilation.
It can be seen ingroovyppexample 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 usegroovypp-all.
Using Groovy++ with Maven
Note, an update is available.
Groovy++ artifacts are now deployed in Maven repository at:
http://groovypp.artifactoryonline.com/groovypp/libs-releases-local/
and
http://groovypp.artifactoryonline.com/groovypp/libs-snapshots-local/
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:
<dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovy</artifactid> <version>1.8.0-beta-1-SNAPSHOT</version> </dependency> <dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovypp</artifactid> <version>0.1.18</version> </dependency> <dependency> <groupid>asm</groupid> <artifactid>asm-all</artifactid> <version>3.2</version> </dependency> <dependency> <groupid>antlr</groupid> <artifactid>antlr</artifactid> <version>2.7.7</version> </dependency> <dependency> <groupid>commons-cli</groupid> <artifactid>commons-cli</artifactid> <version>1.2</version> </dependency> - Use groovypp-all:
<dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovypp-all</artifactid> <version>0.1.18</version> </dependency>
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:
<properties>
<repo>http://groovypp.artifactoryonline.com/groovypp</repo>
</properties>
<repositories>
<repository>
<id>libs-releases</id>
<url>${repo}/libs-releases</url>
</repository>
<repository>
<id>libs-snapshots</id>
<url>${repo}/libs-snapshots</url>
</repository>
</repositories>
<pluginrepositories>
<pluginrepository>
<id>plugins-releases</id>
<url>${repo}/plugins-releases</url>
</pluginrepository>
<pluginrepository>
<id>plugins-snapshots</id>
<url>${repo}/plugins-snapshots</url>
</pluginrepository>
</pluginrepositories>
.. and configure GMaven plugin:
<plugin>
<groupid>org.codehaus.gmaven</groupid>
<artifactid>gmaven-plugin</artifactid>
<version>1.2</version>
<executions>
<execution>
<id>compile-groovy</id>
<phase>process-sources</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<providerselection>1.7</providerselection>
<verbose>true</verbose>
<debug>true</debug>
<stacktrace>true</stacktrace>
<sources>
<fileset>
<directory>${project.basedir}/src</directory>
<includes>
<include>**/*.groovy</include>
</includes>
</fileset>
</sources>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupid>org.codehaus.gmaven.runtime</groupid>
<artifactid>gmaven-runtime-1.7</artifactid>
<version>1.2</version>
<exclusions>
<exclusion>
<groupid>org.codehaus.groovy</groupid>
<artifactid>groovy-all</artifactid>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupid>org.codehaus.groovy</groupid>
<artifactid>groovypp-all</artifactid>
<version>0.1.18</version>
</dependency>
</dependencies>
</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!
If you want to see String’s hashcode, CRC32 or Adler32 colliding (producing same results for different Strings) – run this Groovy script:
import java.util.zip.Adler32
import java.util.zip.CRC32
import java.util.zip.Checksum
def checksum( String s, Class<? extends Checksum> c ) {
Checksum cs = c.newInstance();
cs.update( s.getBytes(), 0, s.size())
cs.getValue()
}
assert checksum( "194.153.241.7", Adler32.class ) ==
checksum( "64.229.15.206", Adler32.class )
assert checksum( "maxtnt05-489.phlpa.fast.net", CRC32.class ) ==
checksum( "bzq-218-115-93.red.bezeqint.net", CRC32.class )
assert "adsl-67-64-91-128.dsl.austtx.swbell.net".hashCode() ==
"h98s18a80n47.user.nortelnetworks.com".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() ==
"/ongoing/pie/0.2/?N=D?M=A?S=A?D=A?N=A?N=A?N=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 ..
Groovy/Maven – Multiline Strings
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 = "http://maven.apache.org/POM/4.0.0"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
""".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).
File.eachFileRecurse() – speedup when filtering directories
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 ( filter.call( file )) { if ( file.isDirectory()) { eachFileRecurse( file, closure, filter ); } else { closure.call( file ); } } } }
Now, having the following filter ( this.skipDirectories is [‘.svn’, ‘build’, ‘dist’] in my case):
Closure recursionFilter =
{
file –>
if ( file.isFile())
{
return ( file.name == ‘pom.xml’ );
}
if ( file.isDirectory() && ( this.skipDirectories.any{ it == file.name } ))
{
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.
GMaven plugin – depends on Groovy 1.6.0 instead of 1.6.3!
GMaven plugin is nice but latest 1.0 version depends on Groovy 1.6.0 which lacks java.lang.String.find() accepting String regex and Closure.
So one needs to configure this plugin as follows:
<plugin> <groupId>org.codehaus.groovy.maven</groupId> <artifactId>gmaven-plugin</artifactId> <version>1.0</version> <configuration> <scriptpath> <element>${project.basedir}</element> </scriptpath> </configuration> <dependencies> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- To make sure latest Groovy version is used --> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.6.3</version> </dependency> </dependencies> </plugin>
Note that I also set ${project.basedir} as scripts directory, more options are available here.
Goldin, the Junior 