The JavaOne crowd is applauding Groovy! And the blogosphere is full of friendly comments towards our dynamic and agile scripting language for the JVM.

Jeremy Rayner (our co-JSR-241 spec lead, and JSR project lead) compiled a list of blog posts related to Rod Cope’s JavaOne presentation, titled “Groovy = Java Technology + Ruby + Python for the JVM”. Rod Cope, OpenLogic’s CTO and Founder, has already given a few talks about Groovy, and evangelizes its use at various events. But he doesn’t only “speak” about Groovy, he’s also eating his own dog food, because his company flagship product BlueGlue embeds over 100,000 lines of Groovy code!

I’m glad I just received my Maven Developer’s Notebook, from O’Reilly. My friend Vincent Massol and Tim O’Brien co-authored this great book on Maven, a definitely needed reading for all those who want to learn more about Maven, or who wants to get started quickly. I had the chance of being one of the reviewers and it allowed me to learn quite a few tricks in the process, at the same time I was converting one of my projects at work to a “mavenized” build process and integrating it inside Luntbuild for continuous integration. I particularly liked the “best practices” aspects both authors managed to give throughout the different labs. This book is a must read, go and get it at your nearest bookstore!

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!