Monday, May 27, 2013

Separating MVEL from Moo

A feature request earlier in the year for Moo, my framework for mapping from objects to objects, was to support accessing private fields as the source for a translation as well as the destination.

This was a bit of a problem, because ever since MVEL was integrated with Moo, Moo has been using MVEL to access all source properties, and I wasn't able to find a way to access a private field using MVEL.

I'm also sensitive to the fact that MVEL is an additional dependency, and while it adds some flexibility to what Moo can accomplish, not everyone needs that flexibility and wants that dependency. The final nails in the coffin are a very low-traffic mailing list where questions often go unanswered and a few bugs that I've been bitten by that don't seem to be getting resolved. Essentially, it's not something I trust completely and as a result, I don't really want Moo to be as tightly coupled to it as it has been in the past.

Changing this, however, is a bunch of work. I'm not looking to remove MVEL altogether, just loosen the couplings so that people can choose to use or not use MVEL when they use Moo. This meant separating what was once a single project into two, giving them a multi-module build, adding an extension mechanism to moo-core that moo-mvel can use, and so forth.

That work is largely complete, but since it was so much work, I picked a bunch of other features that I've been meaning to enhance for some time and threw together a 2.0 release. That work is still underway, but I hope it will be done in the relatively near future.

This leads directly into another topic I've been itching to write up -- dependency relationships. But that's a topic for another post.


  1. What specific bugs are you waiting on fixes for?

  2. There's nothing that outright blocks anything that I'm doing -- so I wouldn't say that I'm waiting on fixes for anything. But, for instance:

  3. By way of a more recent example: