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.

JAX-RS Momentum

It's great to see JAX-RS picking up momentum. I've done work in Restlet, and I'd like to spend some time in Jersey, so it's great to see that I'll have more choices next time.

Next comes tool support, integration, and then ... the world. Although, to be honest, I'd be happier with web services and remoting if I felt that they were consistently being used appropriately. I still find that people consider remoting when they don't need it -- too busy looking for the long-term flexibility and not enough time actually building the immediately necessary functionality.

WADL: A description language for the REST of us

If you must make an API available over a network or over the web, you've got a number of ways to do it. Conventional wisdom these days argues for WS-*, SOAP, SOA, and their ilk. These have a lot of power, but, to be honest, I'm much more likely to use something simple: XML over HTTP.

I'm not going to get into a discussion about the pros and cons of a WS-* approach vs. XML/HTTP, nor the theories behind REpresentational State Transfer. There are lots of places you can go for that.

However, if you are building or consuming APIs using XML over HTTP, it may have occurred to you that there's no consistent way of documenting and describing these services. WADL, the Web Application Description Language, attempts to fill that gap, and it seems relatively sensible.

I'm a little wary, because I've had to create and consume WSDL, and I'm not yet convinced that a description language adds enough value to warrant any additional complexity to the XML/HTTP stack. That said, it's interesting to the applications people have considered for such a thing:

• Generating Documentation from WADL
  
• Generating
• Client libraries in multiple languages from WADL
• WADL from Examples (e.g. in Documentation)
  

Of course, there are alternatives. If you're writing XML over HTTP, are you considering a description language?