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. If you're upgrading from a previous version of Moo, you'll probably want to look at the Upgrading notes below to see how to make the transition as smoothly as possible.

While extracting Moo from the core module, I took the opportunity to upgrade the version to MVEL 2.0.19 and to do some work around precompiling and retaining the MVEL expressions.

(see #14, #83, #9, Extensions)

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.

MVEL Properties

Prior to Moo v2, if you were using Moo, you were using MVEL implicitly. In Moo v2, that becomes a more explicit choice, which is mostly a good thing, but it does mean that when you're upgrading, you'll need to decide if MVEL is important to you.

If you're not sure, I'd suggest starting with Moo Core, and only upgrading to MVEL if you're sure that you need it. For those of you using Maven, that would look like:

<dependency>
    <groupId>com.codiform</groupId>
    <artifactId>moo-core</artifactId>
    <version>2.0</version>
</dependency>

If you know that you want to use the MVEL extension to Moo, or you'd like to give it a try, then use the moo-mvel artifact instead. Again, for Maven users:

<dependency>
    <groupId>com.codiform</groupId>
    <artifactId>moo-mvel</artifactId>
    <version>2.0</version>
</dependency>

You can read more about moo-mvel on the Extensions page.

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 attribute, 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.

Of course, this means that if you were using the itemTranslation attribute, you need to change that to itemClass when you upgrade to Moo v2.0.

(see issue)

Translation to Source

During the extensive changes for Moo v2.0, I took the time to make handling of sources more explicit and complete. In the process, I changed several ‘translation’ expressions to ‘source’ expressions, which match the ‘source properties’ that underly them.

This has resulted in some change to annotations as well as error messages and internals, such as:

• translation attribute on @Property changed to source.
• translation attribute on @CollectionProperty changed to source.

This is consistent with new annotations and classes as well:

• @MapProperty has source, keySource, valueSource
• the new SourcePropertyFactory interface