Release 2.0

Moo v2.0 has not yet been released. It started from a few external user requests and snowballed into a major release with multiple modules and significant internal refactorings.

Although the issue list for the release contains more information, the features of v2.0 are summarized below.

Features

Multiple Modules

Moo v1.0 used an expression library, MVEL, to enable translation expressions that could reach within nested objects or call out to static classes. While MVEL is a solid choice for an expression language, coupling Moo so directly to it had some problems.

For instance, Moo used MVEL for all source property retrieval, which meant that source properties could not be retrieved from private fields, which resulted in a feature request.

I also encountered a few frustrations with MVEL that made me wish the relationship to MVEL were a bit more arm's length. I wrote up some of my concerns in a blog post, if you want to read more about it.

Ultimately, I decided that I did want to continue to use Moo, but that I wanted flexibility for myself and for other people who were using Moo who didn't need MVEL or who wanted the option of using when it added value and not using it when it wasn't needed.

In order to do this, I had to convert Moo to a multi-module project with two modules, moo-core and moo-mvel.

Upgrading

Upgrading from one version of Moo to another is usually not a great deal of work, but there are, at times, changes that you should be aware of or even backwardly-incompatible changes that could pose problems.

itemTranslation to itemClass

Prior to Moo v2, itemTranslation was used as the @Translation attribute used to refer to the class that should be used for the item.

During the Moo v2 development process, this was changed to itemClass, which is perhaps slightly more clear, and itemTranslation was repurposed for the translation expression. However, the translation expression was later changed to itemSource to be consistent with other uses of source expressions.

Having said that, I still prefer the new itemClass name for the attrivute, so I’m sticking with it, taking the v2.0 line as an opportunity to introduce some backwardly-incompatible changes, which I hope won’t cause too much pain for those of you already using Moo.

(related issue)