I put the finishing touches on the second release of one of my open-source projects, Moo, last night. I'd been updating the documentation for a few weeks now to get that in sync with all the code changes that have been taking place. Now that it's finally done, I've released Moo v2.0 up to the Maven central repository.
Moo v2.0 is the first release that was driven more from requests made by users of Moo than for my own needs. If you're using Moo and you'd like to make a request, get in touch over email, twitter, or GitHub, and I'll see what I can do.
For those of you already using Moo, I'd love to hear some thoughts about how Moo v2.0 works for you and what enhancements you still need.
If you're not using Moo, it's a relatively unintrusive way of mapping one object graph to another in Java. Check out the website, the release notes or the wiki to learn more.
Showing posts with label moo. Show all posts
Showing posts with label moo. Show all posts
Friday, May 23, 2014
Saturday, January 11, 2014
Moo v2.0: Release Candidate 1
I've released the first release candidate build of Moo v2.0, which can be found in Sonatype's OSS staging repository if you use Maven, or you could just download one of these JARs directly from the repo:
If you've been using Moo v1.0 and you're using MVEL expressions, then you'll want both of these. If you don't need MVEL expressions, then you can simply use "moo-core" and not bother with the "moo-mvel" extension JAR.
I'll be conducting some tests with these against some of my own projects, and in the meantime, I'll be documenting more accessibly some of the changes to Moo v2.0, which include:
- Translation expressions for collection items
- Factory creation of destination objects
- Translatable maps (key, value, key & value)
- Collection type factors in destination type
- Support for source properties without getters
- Translation ordering (superclass properties before subclass properties)
- Separating MVEL from the core of Moo so that it's an optional add-on.
- MVEL expression pre-compilation.
- Support for translating objects to Strings via toString().
- Translator and annotation caching.
- Dependency upgrades
If you do use the release candidate, let me know how it goes so I can address any issues before putting out the full release.
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.
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.
Subscribe to:
Posts (Atom)