On Releasing an Open-Source Project (Moo v1.0)

Like many developers, I’ve used a large number of open-source projects over the years to get my work done. Also like many developers, I’ve worked for companies that were wary of contributing to open-source projects to any significant degree. Worse, several of these companies attempted to claim the rights to any software built while employed by them, without regard to whether this was built for them, or on their time. These attitudes are common, suspect, and should probably be the subject of another post.

I’ve returned to doing freelance software development and software consulting this year (and, hey, if you need someone to help you with software development, drop me a line). Although working for yourself has some drawbacks, it does come with a lot of freedom. That includes the freedom to work on open-source projects in unbillable time (or, if you have an understanding with your client, even potentially in billable time).

I’ve been taking advantage of that recently, by building a project to map objects to objects, called Moo. I’ve been on projects that have needed something like this a number of times, and teams I’ve been on have built something very similar to this twice before. I’m really hoping this is the last time I’ll have to write this particular piece of code, because from now on I’ll be able to adopt my own code, even if I’m working for another company.

In order to increase the odds that I’ll be able to adopt it, and to help as many other teams as I can, I’ve used the BSD license. That means you can bury Moo inside your own work and you don’t have to pay me, or adjust the license of your project. If you want to credit me in some way, that’d be cool, but mostly I just want to make sure that, if Moo is useful to you (or to me!) there aren’t any obstacles to that.

Moo v1.0 Released

I’m happy to announce the release of Moo v1.0, an open-source, BSD-licensed project for Mapping Objects to Objects.

What’s It For?

Moo allows you to map objects to objects, by copying data from one object or object graph and creating or updating another object/graph. Along the way, Moo can do translations, flattening objects, calling methods, and otherwise helping to map objects that aren’t identical copies of each other.

Moo is the sort of tool you use to work around a problem, not fix it. If you find yourself wanting something like Moo, you should probably ask yourself — am I just papering over an architectural issue or a limitation of a framework that I should be trying to resolve in some other way?

That said, I’ve needed Moo before and I’ll need it again; some problems are too much trouble to fix when there’s a reasonable workaround. I’ve used Moo for data transfer objects (DTOs) and when serializing an object/graph.

When possible, I like to use a rich domain model throughout an application, rather than using a domain-model in some kind of service layer and data transfer objects in the interface tier. But there are times when data transfer objects are more palatable. For instance, if you find yourself on a project using GWT and Hibernate together, you’ll discover that GWT serialization and Hibernate proxy objects aren’t a match made in heaven, and you might find yourself wanting some data transfer objects.

If you like to use well-connected object models, you’ll also find that the default serialization approach for GWT and lots of web service frameworks don’t have great mechanisms for tweaking what parts of the object graph you return, particularly if you want to make those decisions differently depending on the service method being invoked.

If you’re using Moo, you can have a domain model object like User, and return List from lists and queries, and return a UserDetails object from a more detailed ‘get’ query. I’ve written an example like this into the User Guide for Moo.

What Did You Learn?

Well, for starters, GitHub’s pretty cool. I considered using Google Code with Mercurial, or bitbucket, but I wanted to spend some more time with git and GitHub. I’m glad I did, I’ve been really pleased with GitHub. I’m not yet sold on its issue tracker, but for now I’m using all the pieces simply because it’s nice to have them all integrated.

And Sonatype’s Maven repository hosting for open-source projects is great, since it uses Nexus, and syncs with central.

On the other hand, I hadn’t signed Maven artifacts with the maven-gpg-plugin before, and as is typically with less-used Maven plugins, there were a couple significant bugs that I had to track down before I could deploy a GPG-signed release.

Next Up

I have a few more open-source projects planned, starting with some work I did to support concurrent testing using JUnit. I’ll be mixing up this kind of open-source work with side projects and paying gigs, so I’m not making any guarantees about timelines.

If you do end up using Moo, drop me a line, I’d love to hear about it.