Creating Collections

Groovy really shines for this one, making the creation of Lists and Maps, empty or populated, an absolute breeze. Java has some help for creating basic Lists but begins to struggle when creating maps. This is an area that google-collections can help in, especially in regards to creating immutable Maps.

//Empty Lists
        List<String> groovyList = []
        List<String> javaList = new ArrayList<String>()
        List<String> googleList = Lists.newArrayList()  //can omit generics

//Populated Lists
        List<String> groovyList = ["1", "2"]
        List<String> javaList = Arrays.asList("1", "2")
        List<String> googleList = Lists.newArrayList("1", "2")

//Immutable Lists
        List<String> groovyList = ["1", "2"].asImmutable()
        List<String> javaList = Collections.unmodifiableList(Arrays.asList("1", "2"))
        List<String> googleList = ImmutableList.of("1", "2")

//Empty Maps
        Map<String, String> groovyMap = [:]
        Map<String, String> javaMap = new LinkedHashMap<String,String>()
        Map<String, String> googleMap = Maps.newLinkedHashMap()

//Immutable Maps
        Map<String, String> groovyMap = ["a":"1", "b":"2"].asImmutable()

        Map<String, String> javaMap = new LinkedHashMap<String,String>()
        javaMap.put("a", "1")
        javaMap.put("b", "2")
        javaMap = Collections.unmodifiableMap(javaMap)

        //OR(works only in Java, will not compile in Groovy)
        Map<String, String> javaMap = new LinkedHashMap<String, String>()
        {
            {
                put("a", "1");
                put("b", "2");
            }
        };

        Map<String, String> googleMap = ImmutableMap.of("a", "1", "b", "2")  //clunky syntax but it works

Filtering Collections

Groovy provides the very handy ‘findAll’ method that allows you to filter a Collection by applying a Closure. Google-collections provides similar facilities using the Predicate interface and two filter methods available statically on Collections2 and Iterables. This would also be a lot more readable if the Predicate definition were extracted but I wanted to show that it’s still possible to create them in-line quickly.

import static com.google.common.collect.Collections2.*

List<Integer> toFilter = [1, 2, 3, 4, 5]
List<Integer> groovyVersion = toFilter.findAll{ it < 3}
List<Integer> googleVersion = filter(toFilter, new Predicate<Integer>()
    {
        public boolean apply(Integer input)
        {
            return input < 3;
        }
    };)

Joining Collections into a String Representation

This one has come up pretty often over the years, and it’s not surprising that where the JDK hasn’t provided, enterprising developers have added support through libraries. The problem is: given a Collection of objects, create a String representation of that Collection suitable for view from a consumer of the system. And admit it – the first time you hand-coded the algorithm you left a trailing comma, didn’t you? I know I did.
Groovy has fantastic support for this use-case by simply including the ‘join’ method on Lists. Google-collections utilizes static calls on the Joiner class along with a simple DSL-like syntax to achieve the same effect. Throw in a static import to make it even more concise and it does a fine job. These two examples yield the same result.

import static com.google.common.base.Joiner.*
def toJoin = ['a', 'b', 'c']
def separator = ', '

//groovy version
def groovyJoin = toJoin.join(separator)

//google-collections version
def googleJoin = on(separator).join(toJoin)

And google-collections also supports join for Maps, something missing from Groovy(although not very hard to implement).

import static com.google.common.base.Joiner.*
def toJoin = [1: 'a', 2: 'b', 3: 'c']
def separator = ', '
def keyValueSeparator = ':'

//results in '1:a, 2:b, 3:c' which is essentially what is returned from Groovy map.toMapString()
def googleVersion = on(separator).withKeyValueSeparator(keyValueSeparator).join(map)

//results in '1 is a and 2 is b and 3 is c'
googleVersion = on(" and ").withKeyValueSeparator(" is ").join(map)

//doing the same in Groovy is slightly more involved, but really not that bad
def groovyVersion = toJoin.inject([]) {builder, entry ->
            builder << "${entry.key} is ${entry.value}"
            builder
        }.join(' and ')

Multimaps

Multimaps are one of the more interesting parts of google-collections, at least to me. Have you ever found yourself writing code to create a Map of keys to Lists? Well the various Multimap implementations in google-collections mean you never have to write that boilerplate kind of code again. Here’s a “first-stab” effort to simulate a fairly generic Multimap with pure Java code.

public class JavaMultimap
{
    private Map<Object, List<Object>> multimap = new LinkedHashMap<Object, List<Object>>();

    public boolean put(Object key, Object value)
    {
        List<object> objects = multimap.get(key);
        objects = objects != null ? objects : new ArrayList<object>();
        objects.add(value);
        multimap.put(key, objects);
        return true;
    }
}

And the same thing in Groovy, achieving a slightly smaller version.

class GroovyMultimap
{
    Map map = [:]

    public boolean put(Object key, Object value)
    {
        List list = map.get(key, [])
        list.add(value)
        map."$key" = list
    }
}

I did some primitive timings comparing Java, Groovy and google-collections Multimaps implementations and, as you’d pretty much expect, google clearly takes the lead. Where things really start to get interesting though is when you start using the Multimap in Groovy code. Imagine if you will that you want to iterate over a collection of Objects and map some of the properties to a List. Here’s a contrived example of what I’m talking about, but applying this same pattern to domain objects in your application or even a directory full of xml files is pretty much the same. If you look closely you’ll notice that Groovy actually makes this a one liner to extract all values for a property across a List of Objects(used in the assertion), but I imagine that Multimap is probably a better alternative for large data sets.

class GoogleCollectionsMultiMapTest
{
    private Random random = new Random()

    @Test
    public void testMultimap()
    {
        def list = []
        10.times {
            list << createObject()
        }
        List properties = ['value1', 'value2', 'value3']
        Multimap multimap = list.inject(LinkedListMultimap.create()) {Multimap map, object ->
            properties.each {
                map.put(it, object."$it")
            }
            map
        }
        properties.each {
            assertEquals (multimap.get(it), list."$it")
        }
    }

    Object createObject()
    {
        Expando expando = new Expando()
        expando.value1 =  random.nextInt(10) + 1
        expando.value2 =  random.nextInt(100) + 100
        expando.value3 =  random.nextInt(50) + 50
        return expando
    }
}

So Where Does This Get Us?

Between google-collections and the newer guava-libraries that contain it, there’s lots of help available for simplifying programming problems and making your code more readable. I haven’t even touched on the newly available support for primitives, Files, Streams and more, but if you’re interested in reducing the amount of code you write AND simultaneously making it more readable you should probably take a look. There’s a very nice overview available in part one and part two by Aleksander Stensby. And here’s a closer look at what google-collections can do for you.

Source Code

As per usual, source code is available at github as a maven project. Big thanks to the Spock team for sharing how they configure GMaven to properly utilize Groovy 1.7. Please feel free to take a look and comment here. Thanks!

Tweet This Post

Related posts:

1. My favorite new Groovy trick
2. Groovy and Glazed Lists with Grape
3. Using the TestNG DataProvider with Groovy

The Pretty Pictures

Here are the three images to test against. In order to put them in a suitable format for the open source tesseract-ocr program to process we need to make them bigger, remove the background noise and transform them into a ‘tif’ format. The python program we’re porting utilizes the PIL library for image handling and the pytesseract library for wrapping tesseract; I didn’t look very hard for java equivalents and just coded the required functions directly.

Reading in the Image

The python code for this is three lines, one to load the image and a couple more to convert it into a format suitable for directly manipulating pixel color through RGB values. Groovy takes a bit more to do the same, but being able to use a ‘with’ block makes interacting with the Graphics object a lot cleaner than the same Java code

//python
from PIL import Image
img = Image.open('input.gif')
img = img.convert("RGBA")
pixdata = img.load()

//Groovy
BufferedImage image = ImageIO.read(new File(fileName))
BufferedImage dimg = new BufferedImage(image.width, image.height, BufferedImage.TYPE_INT_ARGB)
dimg.createGraphics().with {
    setComposite(AlphaComposite.Src)
    drawImage(image, null, 0, 0)
    dispose()
}

Removing the Background Noise

In both cases we’re doing essentially the same thing: finding all non-black pixels and setting them to white. This leaves only the actual embedded text to stand out. Being able to utilize the Java Color constants makes the Groovy version a little more readable, IMO, but otherwise the two pieces of code are generally equivalent.

//python
for y in xrange(img.size[1]):
    for x in xrange(img.size[0]):
        if pixdata[x, y] != (0, 0, 0, 255):
            pixdata[x, y] = (255, 255, 255, 255)

//Groovy
(0..<dimg.height).each {i="" -="">
    (0..<dimg.width).each {j="" -="">
        if (dimg.getRGB(j, i) != Color.BLACK.RGB)
        {
            dimg.setRGB(j, i, Color.WHITE.RGB)
        }
    }
}

Resizing the Image

Python‘s library usage really shines here, making this a one line call. Not quite the same in Java-land, although again there’s probably a better way to do this(I just don’t know it offhand).

//python
big = im_orig.resize((116, 56), Image.NEAREST)

//Groovy
dimg = resizeImage(dimg, 116, 56)
...
def resizeImage = {BufferedImage image, int w, int h ->
    BufferedImage dimg = new BufferedImage(w, h, image.type)
    dimg.createGraphics().with {
        setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR)
        drawImage(image, 0, 0, w, h, 0, 0, image.width, image.height, null)
        dispose()
    }
    return dimg
}

By this point the original images now look like this, and are almost ready for OCR.

Converting to a tif File

This one turns out to be a bit of a PITA in Java and particularly on a Mac, and represents the bulk of the Groovy code. Unfortunately it is also the only format that tesseract appears to accept ‘out of the box’. After googling the fun that is JAI and working with the .tif(f) format with it on a Mac, I ended up taking the code kindly provided in this blog post and Groovified it a bit to make a working transformation. Thanks very much to Allan Tan for that. One more time, there’s likely a better/easier way to do this, but honestly it’s more effort than I’m willing to put in on a weekend afternoon just to satisfy my curiosity.

//python
ext = ".tif"
big.save("input-NEAREST" + ext)

//Groovy
void convertToTiff(String inputFile, String outputFile)
{
    OutputStream ios
    try
    {
        ios = new BufferedOutputStream(new FileOutputStream(new File(outputFile)))
        ImageEncoder enc = ImageCodec.createImageEncoder("tiff", ios, new TIFFEncodeParam(compression: TIFFEncodeParam.COMPRESSION_NONE, littleEndian: false))
        RenderedOp src = JAI.create("fileload", inputFile)

        //Apply the color filter and return the result.
        ColorConvertOp filterObj = new ColorConvertOp(ColorSpace.getInstance(ColorSpace.CS_sRGB), null)
        BufferedImage dst = new BufferedImage(src.width, src.height, BufferedImage.TYPE_3BYTE_BGR)
        filterObj.filter(src.getAsBufferedImage(), dst)

        // save the output file
        enc.encode(dst)
    }
    catch (Exception e)
    {
        println e
    }
    finally
    {
        ios.close()
    }
}

OCR with Tesseract-OCR

Finally we need to pass the processed image to tesseract so it can ‘read’ it for us. Again, the python library makes this a breeze, but calling out to a command line program with Groovy is so simple that it ends up being about the same. Tesseract itself is available as a macport, as well in downloadable unix binaries and a windows executable so installing the software is a breeze.

//python
from pytesser import *
image = Image.open('input-NEAREST.tif')
print image_to_string(image)

//Groovy
def tesseract = ['/opt/local/bin/tesseract', tmpTif, tmpTesseract].execute()
tesseract.waitFor()
return new File("${tmpTesseract}.txt").readLines()[0]

Testing it out

To test it out I implemented the code in a maven project, iterate over the images and write out intermediate results to a temp directory. And it only works on two out of three of the cases. For some reason tesseract insists on consistently seeing ‘e4ya’ as ‘e4ga’. I tried to see if I could get it working by tweaking the image manipulation parameters and the order of operations(resizing before removing the background noise for instance) but that just caused the other cases to fail as well. Since in the final image the ‘y’ seems pretty clear, it’s more likely that tweaking tesseract configuration might yield better results.

public void testPrintImage()
{
    def breaker = new CaptchaBreaker()
    /* tesseract interprets "e4ya" as "e4ga" unfortunately */
    ['9koO', 'jxt9'/*,'e4ya'*/].each {String imageName ->
        def fileName = "src/test/resources/${imageName}.gif"
        assertEquals("Testing $imageName",imageName, breaker.imageToString(fileName))
    }
}

C’est Finis

I had some fun playing with areas of Java that I don’t usually interact with, and gained some appreciation for the diversity and ease-of-use exposed by just a couple of python libraries. It’s comforting to note that I was able to implement all of the required functionality from those libraries in < 90 lines of Groovy. With a little more effort I think the final product could be tweaked to avoid the intermediate file system reads/writes as well, but that’s for another day.
Source code is available on github if you’d care to take a look, and thanks for stopping by!

Tweet This Post

Related posts:

1. Different Flavors of Embedded Groovy in Java Apps or “How To Make your Java Groovier!”
2. Groovy and CSV: How to Get Your Data Out?
3. Groovy and Hibernate Validator for Dynamic Constraints

A DataProvider method in TestNG can return either a two dimensional Object array or an Iterator over each of the test parameters. A consumer of that method will be triggered once time for each set of parameters from the provider. Parameters are injected into the consumer method at execution time.
This greatly eases testing various expectations that run through essentially the same path of execution.

Here’s the simple method under test, courtesy of this example on Groovy Almanac

    /**
     * Use the Groovy added List.inject() method to sum a list of numbers.
     */
    def sum(list)
    {
        def sum = list.inject(0) { sum, item -> sum + item }
    }

And here’s the corresponding DataProvider test harness. The test is injected with a List of numbers to sum and the associated total expected for each case.

    @DataProvider (name = "test1")
    public Object[][] createListInjectSumData() {
        def array = new Object[3][]
        array[0] = [[1, 2, 3], 6] as Object[]
        array[1] = [[2, 4, 6], 12] as Object[]
        array[2] = [[3, 6, 9], 18] as Object[]
        return array
    }

    @Test (dataProvider = "test1")
    void testListInjectSummation(list, expectedSum) {
        Assert.assertEquals(new ListInjectExample().sum(list), expectedSum)
    }

I’ve put the maven project I used to demo this up on github here. Mostly just because I’m having a great time using Git lately.

Tweet This Post

Related posts:

1. Achieving Groovy-like Fluency in Java with Google Collections
2. Different Flavors of Embedded Groovy in Java Apps or “How To Make your Java Groovier!”
3. Breaking Weak CAPTCHA in… slightly more than 26 Lines of Groovy Code

No sooner had Manfred let loose a message on the Tweetosphere than Andres Almiray very graciously offered up some free copies of the upcoming book Griffon in Action to give away at the meeting. Thanks for that Andres!

The company I work for, Genologics, also gave me permission to publish a presentation that I gave recently at work as a Groovy primer for other members of the development staff. Thanks for that Cliff!

I demonstrated some code in SwingPad and created an application using a GMaven archetype to show off some of the sweetness that Groovy adds to the Java toolbox. It’s worth noting that even though that page doesn’t say it, GMaven recently released a 1.0 final verison(NICE!)

I’ve attached the presentation and some of the source code examples for anyone who might be interested, including the maven project that contains a variety of MOP, builder and GDK extension samples.

GroovyTalk

groovyDemo

SwingPad1

GroovyMailRoute

Prefusebuilder

SwingThreadingExample

Tweet This Post

Related posts:

1. VIJUG Griffon/Groovy Presentation
2. A One Day Griffon Application/Presentation
3. Achieving Groovy-like Fluency in Java with Google Collections

In order to test drive Gracelets, I took an existing Seam web-app and configured the web.xml with the GraceletsViewHandler in place of the standard SeamListener. I generally use Maven for dependency management, and I couldn’t find a repository hosting Gracelets so I installed the downloaded jars into my local repository and adding them to the web-app. The JBoss Seam Extension is also required.

mvn install:install-file -Dfile=gracelets-api-2.0.0.jar -DgroupId=gracelets -DartifactId=gracelets-api -Dversion=2.0.0 -Dpackaging=jar -DgeneratePom=true
mvn install:install-file -Dfile=gracelets-impl-2.0.0.RC2.jar -DgroupId=gracelets -DartifactId=gracelets-impl -Dversion=2.0.0.RC2 -Dpackaging=jar -DgeneratePom=true
mvn install:install-file -Dfile=jboss_seam_2.0.0_all-1.0.11.jar -DgroupId=gracelets -DartifactId=jboss-seam-extension -Dversion=1.0.11 -Dpackaging=jar -DgeneratePom=true

<dependency>
        <groupid>gracelets</groupid>
        <artifactid>jboss-seam-extension</artifactid>
        <version>1.0.11</version>
</dependency>
<dependency>
        <groupid>gracelets</groupid>
        <artifactid>gracelets-api</artifactid>
        <version>2.0.0</version>
 </dependency>
 <dependency>
        <groupid>gracelets</groupid>
        <artifactid>gracelets-impl</artifactid>
        <version>2.0.0.RC2</version>
 </dependency>

The application was deployed as usual and fired up without a problem. For a test page I just created an index.groovy file in the root directory. According to the docs, a .groovy extension trumps .xhtml so that effectively replaced the front page of the app. Here’s the standard first page of a new web-app(straight from the Gracelets examples), with the xhtml builder.

xh.html {
     head { title("Hello World Example") }

     body {
         print { "Hello World @ " + new Date() }
     }
}

Not bad, let’s compare to the standard Facelets version, using a file based on the standard seam-gen created index.xhtml file. I’ve bound the instantiation of the Date object to a backing bean, since you can’t make an inline call to do it a standard Facelets view. I seem to recall seeing that Seam kept a component available to provide the present Date/Time, but I couldn’t find it offhand today.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view contentType="text/html"
        xmlns="http://www.w3.org/1999/xhtml"
        xmlns:ui="http://java.sun.com/jsf/facelets"
        xmlns:h="http://java.sun.com/jsf/html"
        xmlns:f="http://java.sun.com/jsf/core"
        xmlns:a="http://richfaces.org/a4j"
        xmlns:s="http://jboss.com/products/seam/taglib">
    <html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
        <title>Hello World Example</title>
        <ui:insert name="head"/>
    </head>
    <body>
    Hello World @ #{backingBean.date}
    </body>
    </html>
</f:view>

Notice I’ve also left the Seam and RichFaces tab library namespaces in the xml declaration. Although the Gracelets docs didn’t seem to easily confirm this, inclusion of the JBoss Seam extension also makes those libraries and their associated builders available by default for Gracelets views. Here’s a final example to leave you with that incorporates a couple of elements from those libraries and a quick and dirty use of .each for rendering, and even a couple of screenshots to show off the progression.

def loremIpsum = '''
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin tempor, mauris sed volutpat consequat, risus tellus ultrices
tortor, at sollicitudin felis erat vitae augue. Pellentesque habitant morbi tristique senectus et netus et malesuada fames
ac turpis egestas. Vestibulum tincidunt egestas viverra. Integer ullamcorper, ipsum id malesuada sollicitudin, nisl velit
ultricies purus, eu aliquet diam mi sit amet eros. Quisque arcu orci, consequat dictum vehicula a, pellentesque eu nisl.
'''
xh.html {
     head { title("Hello World Example") }
     body {
         s.div(id:'aSeamDiv', rendered:'true') {
            r.panel(header:'A RichFaces Panel') {
                println { "Hello World @ " + new Date() }
                a('MyBlogLink', href: 'http://www.kellyrob99.com/blog')
            }
         }
         r.separator()
         r.spacer()
         r.simpleTogglePanel(header:'A RichFaces TogglePanel'){
            println loremIpsum
         }

         def tableModel = loremIpsum.tokenize()[0..10]
         def tableModel2 = loremIpsum.tokenize()[11..20]
         table {
            tr {
                td {
                    tableModel.each { println it }
                }
                td {
                    tableModel2.each { println it }
                }
            }
         }
     }
}

Not bad at all. I won’t bore you with the equivalent xml version – suffice it to say it takes up a lot more space. I haven’t even touched on the easy component/library features Gracelets provides yet, but I am already quite impressed simply by the replacement of xml with an equivalent but sparser syntax. And I don’t miss the need for closing tags much either. The documentation for the project is quite complete, rich with examples, at least for the standard jsf components(hint hint – more examples using Seam and RichFaces would be appreciated!) Give it a try and decide for yourself, but if it keeps going this way, it might become a reasonable alternative for Grails.

[View with PicLens]

Tweet This Post

Related posts:

1. StreamingMarkupBuilder for Groovy-er xml
2. Groovy and Hibernate Validator for Dynamic Constraints
3. Bamboo, Grails and Git for Continuous Integration

So what does Groovy add to the mix to make it an attractive option on top of(or instead of) bash on its own? Dependency management, lean distribution and testability all jump to mind.

Dependency Management

Grape gives you the same stability that Maven provides. Any script can load any Java library is wants to utilize into the classpath at runtime using your existing repository or an available internet connection.

Lean Distribution

Because Grape utilizes a central repository, all dependencies are shared across the entire system. Scripts with extremely small footprints can do some pretty big things. Recently I’ve seen examples of parsing html using TagSoup(I swear I originally saw that example somewhere else but for the life of me can’t find it now), Apache Camel integration(and again) and even spawning a local HSQL database, complete with Hibernate. Within a very sparse number of lines, you can do more than you could ever imagine with plain Java, and I’m more than willing to admit that I wouldn’t know where to start with bash to do any of the stuff I just mentioned.

Testability

The only thing that separates a stand-alone Groovy script from a Groovy class on the command line is the #!. If you’re willing to launch the script on the command line explicitly using the ‘groovy’ executable you can abandon that. So now the difference becomes ‘./groovyScript’ versus ‘groovy groovyScript’. But…. that same script is now ripe and ready to be included in the test framework you use everyday for regular project development. You can easily compose it into unit-testable methods and treat it like any other part of a large and rapidly evolving software project – things that I’ve always found inherently difficult with a command line script. Mostly I find that the truly useful scripts and snippets – the ones that are used regularly by developers on a day to day basis – are the ones that also never end up under source control, and don’t get the benefit of evolutionary change that most code gets.

Building upon the example included in the InfoQ Groovy 1.6 launch notice, here’s the quick and dirty addition of a JXTable component for showing the results of parsing all links from an html page with TagSoup. A text field is used to bind the url and a click of the button starts it off. It’s not pretty, but it did take less than 10 minutes to do so judge for yourself. Run this script from the command line using the groovy command (V1.6+).

import org.jdesktop.swingx.JXTable
import javax.swing.*

@Grab(group='org.swinglabs', module='swingx', version='0.9.3')
@Grab(group='org.ccil.cowan.tagsoup', module='tagsoup', version='0.9.7')
def getHtml(url) {
       def parser = new XmlParser(new org.ccil.cowan.tagsoup.Parser())
       parser.parse(url)
}
def data = [ ]

def my = groovy.swing.SwingBuilder.build {
       frame = frame(title:'Groovy Grab Test', size:[800,500], show:true, pack:true, defaultCloseOperation: WindowConstants.DISPOSE_ON_CLOSE) {
       actions(){
             action(name:'Fetch', id:'fetchAction')
             {
                   data.clear
                   getHtml(urlField.text).body.'**'.a.@href.each{ data << [url:it] }
                   frame.repaint()
             }
       }
       boxLayout(axis: BoxLayout.Y_AXIS)
       scrollPane() {
             myTable = table(new JXTable(columnControlVisible:true)){
                   tableModel(list:data){
                   propertyColumn(header: 'URL', propertyName: 'url')
             }
       }
 }
       textField(id:'urlField')
       button(fetchAction)
 }
}

Since I work for an organization that uses maven extensively for dependency management, most of the libraries that come to mind as handy bash replacements are already available in my local repository. Apache commons, Google collections, and most importantly – any libraries that are specifically dealing with your own products – all are at your fingertips! Even better, since most of the tasks that commonly fall to scripting are pretty low level (moving files around, etc), there are easy alternatives.

AntBuilder, for instance, is baked into Groovy, and provides a great abstraction around most of the desired functionality you want in a scripting environment. Moving files, doing text replacement,tarring files, sending mail – anything that Apache Ant can do, AntBuilder can do. But without all of that infuriating and frustating xml. An example(complete with exception handling!) courtesy of Andrew Glover, in this article.

ant = new AntBuilder()
ant.mkdir(dir:"/dev/projects/ighr/binaries/")

try{
       ant.javac(srcdir:"/dev/projects/ighr/src",
       destdir:"/dev/projects/ighr/binaries/" )

}catch(Throwable thr){
       ant.mail(mailhost:"mail.anywhere.com", subject:"build failure"){
             from(address:"buildmaster@anywhere.com", name:"buildmaster")
             to(address:"dev-team@anywhere.com", name:"Development Team")
             message("Unable to compile ighr's source.")
       }
}

Where you REALLY need it, you of course are still able to call on any and all of the *nix powertools you might like in a Groovy script. Personally, more and more I find that building and testing the script in my chosen IDE, and using the libraries I’m most comfortable with to do it, is a much more productive and enjoyable experience.

P.S. Gotta apologize about the code formatting – if anyone knows a wordpress syntax highlighting plugin that DOESN’T blow away your formatting or randomly replace the text with html entities, gimme a shout please!

Tweet This Post

Related posts:

1. Griffon bash completion…
2. Groovy and Glazed Lists with Grape
3. Gracelets and Seam – a DSL for Facelets and Groovy with easy integration

# Griffon completion for the bash shell
#
_griffon()
{
   local cmds cur colonprefixes
   cmds="bootstrap clean compile console create-app           \
      create-fest-test create-integration-test create-mvc     \
      create-plugin create-script  create-unit-test           \
      create-fest-test run-fest -cobertura help init          \
      install-plugin list-plugins package package-plugin      \
      plugin-info release-plugin run-app run-applet run-fest  \
      run-webstart set-proxy set-version shell stats test-app \
      test-app-cobertura uninstall-plugin upgrade"
   COMPREPLY=()
   cur=${COMP_WORDS[COMP_CWORD]}
   # Work-around bash_completion issue where bash interprets a colon
   # as a separator.
   # Work-around borrowed from the darcs work-around for the same
   # issue.
   colonprefixes=${cur%"${cur##*:}"}
   COMPREPLY=( $(compgen -W '$cmds'  -- $cur))
   local i=${#COMPREPLY[*]}
   while [ $((--i)) -ge 0 ]; do
      COMPREPLY[$i]=${COMPREPLY[$i]#"$colonprefixes"}
   done

        return 0
} &&
complete -F _griffon griffon

Add this to your .bash_profile file and you’re good to go for saving a whole bunch of keystrokes and calls to ‘griffon help’.

Tweet This Post

Related posts:

1. Groovy and Bash – can scripting get much easier?
2. SwingSet on Griffon
3. Griffon SwingX Fest testing