A new milestone of Groovy was released a few days ago. The general goal of this release was quality. 80-90% of our work was targeted at improving the user experience, as much as we could. One of the main complaints so far has always been regarding the ugly error reporting that Groovy was generating. Whether that be in the shell, or embededed, or when compiling your Groovy source code. It was pretty hard to figure out what the error was by looking at a meaningless message and hundreds of lines of exceptions.

I played with Lucene today to index a CSV file representing the Unicode characters metadata. Lucene is so easy and fun to use, that’s really the kind of libraries I like very much. I took some inspiration from my friend Jeremy who played with Lucene and Groovy recently, by translating into Groovy some examples of Lucene in Action.

I’ve always been interested in i18n issues, charset/encoding malarkey, and so on. It’s always a pain to deal with… but it’s pretty damn interesting, and that’s often a problem that native English speakers overlook.

Recently, on Maven’s user list, someone wanted to be able to script Maven with Groovy, like it was already possible with BeanShell or Jython thanks to specific Jelly tags. But unfortunately, Maven didn’t provide that kind of support for Groovy.

But there are good news on that front since Jeremy Rayner contributed a nice Groovy Ant task.

That Ant task will be available in the upcoming Groovy release (jsr-02), so if you want to play with Maven and Groovy, you’ll have to build Groovy from sources in the meantime. But I’m going to reveal how to script Maven with Groovy in advance.

My little puzzle of the day is to find how to remove accents from a String. There are different alternatives, different strategies, but none really suits my needs – or my taste.

The naive approach is to use String.replace() to replace manually all characters, with a correspondance table, like “é” should be replaced with “e”, etc. That’s fine for some languages I know, like French or German, or even some latin languages, since we share the same alphabet. But with Russian, Greek, or some asian languages, my knowledge won’t suffice! So I can’t reliably produce a big hashtable with that knowledge. What a pity!

Maven is a pretty powerful tool, but sometimes, simple things can get complicated… I had to customize my build to upload some files through FTP. But it wasn’t just a mere artifact to upload through FTP to the enterprise repository, so I couldn’t use Maven’s artifact plugin and its FTP method. So the solution was to use Ant’s optional FTP task.

At first, it doesn’t seem very complicated, since Maven can basically use any Ant task very easily, but the fact is that this optional Ant task is dependent on another library that you have to add to Maven’s root classloader, otherwise you’ll get a NoClassDefFound! And moreover, I couldn’t even find NetComponents on ibiblio!

When working with Word documents, you’d often like to be able to extract relevant content automatically thanks to some scripts. That’s exactly what I wanted to do this afternoon. I have a Word document which contains some scripts written with a specific style, and I wanted to extract those snippets, so that I may be able to check that they compile or that the unit tests they represent be asserted successfully.

At work, I’m using Castor XML to Java binding to marshall/unmarshall messages in my Web Services, inside a custom framework (Struts, OJB, JAXM, etc). I have defined my messages as XSD Schemas, and I’m using Castor’s Maven plugin to auto-generate my Java classes at build time.

All is good and well… Hmm, almost! Castor’s SourceGenerator generates Java classes for complex types and elements, but not for simple types, and unfortunately, I badly needed to marshall those simple types as well. But fortunately, I’ve found a little trick to transform simple types to complex types, so that Castor can generate the associated Java classes, with its useful and handy marshall() methods.

Rails is kinda cool. Any framework that ease the development of CRUD-oriented webapps is a real time saver. There’s been a lot of well-deserved hype around Ruby on Rails lately. But I’m not sure that’s really that revolutionary. I’ve always thought that a good Java Web framework can do the same. Perhaps with a few more lines of code, since we all know that Java tends to be more verbose than some scripting languages. But overall, does it really matter? Especially since you tend to be much more productive in Java with a top-notch IDE like IntelliJ!

I think Angsuman diserve an answer.

It looks like Groovy is in dire needs of a project manager.

We’ve got one already. Of course, he’s been pretty busy with his Active* projects lately, but I think now he’s really back on the project. It’s often hard to cope with both a demanding job, and a demanding Open Source project. It’s tough to find time for both. Fortunately, he’s not alone on the Groovy project. While he was too busy, I took the interim and maintained Groovy and managed to deliver a few successful betas with a lot of bug fixes. But that’s just the tip of the iceberg. In November, with Jeremy, we organized a JSR meeting, and I’ve recruited a few new commiters to help us solidify our groovy-core base, so that it is able to receive the upcoming new parser. And the JSR work and discussions never stopped.

Incredible, I’ve just learnt that Groovy was dead, according to Mike! So I understand that’s why Cédric would like to know the final date for the burial.

It’s interesting to see how much pressure the Groovy project has on its little shoulders. So far, to my knowledge, I don’t really see any other OSS project for which the users and the blogosphere had so many expectations. Well, back in time, 6 months ago, yeah, we could’ve said Groovy was somewhat a zombie, but I don’t think that’s true anymore, with the latest months activity. We’re certainly not good at public relations these days, we’ve got some efforts to make on that front.