Saturday, 24 April 2010

Announcing: Madura Objects

One of the reasons this blog has been a bit quiet is that I have been working furiously on Madura Objects. Now I have uploaded it to Github for all the world to see (if it wants).

What is it? Imagine you have a bunch of Java objects that represent real things like Customer, Order, Address, Product etc. We spend a lot of time plumbing these kinds of objects in our applications. Typically we write business logic to manage them, validate them, persist them etc. Using JAXB we have a way to serialise Java objects to and from XML, and I use this a lot when building web services.

Thanks to Hyperjaxb3 we can also take these same objects and persist them to Hibernate (and other places which I have not yet tried). This all simplifies the plumbing logic hugely. But I wanted to do a little more and the JAXB approach easily lends itself to transparently adding more 'stuff' to the Java objects.

I'll explain that a little more. You actually define your objects in XSD, pass them through the JAXB/XJC utility and that generates your Java classes. The resulting classes are just beans (empty constructor and getters and setters for each field). But, depending on what plugins you specified in the XJC command, there might be other stuff as well.

Now, for Madura Objects, what I did was add interceptors into the resulting setters. These do some logic based on the annotations on the relevant field and this allows them to do field validation. The annotations can be specified in various ways in the XSD file, so you get declarative validation completely transparent to your surrounding code.

This is different from Hibernate Validation (though I have kept the annotations as similar as possible). Hibernate Validation assumes you call the setters and then call a validator method. MaduraObjects does it automatically and it rejects the value without actually setting it. That means your objects are always clean and you don't have to write fixup logic to undo bad values.

There is somewhat more but I'll go into that next time. But you can check it out right now at Madura Objects.

Sunday, 11 April 2010

Water and luck.

Sometimes you get lucky.

It has been very dry here lately. Further north it is much worse but we average about 1500mm of rain a year normally, and January and February are our driest months. But it is now April and we've had a few showers over the last month but nothing much. Our pond is the lowest I have seen it since it was first dug (over 10 years ago). It is rain fed, not part of a stream. Our domestic water comes from a tank that is fed with water from our roof, just like all our neighbours. Our sheep use that water as well.

Our neighbours are buying water. A tanker truck delivers it and fills up their water tanks. But we are okay. Why? Because we got lucky.

Two reasons. First, we have a composting toilet which uses no water. Most households use 30% of their water flushing their toilet. We use 0%. We also have a front loading washing machine and that uses less then a top loading one. These were deliberate decisions, partly to conserve water but also because we liked the idea of using the output from the toilet as compost, and front loading washing machines give a better wash.

But where we really got lucky was in the house design. We had been looking at abbeys in southern France and that was what we wanted our house to look like. I certainly did not make the connection that these places are built for a dry climate. Their wide roofs are ideal for gathering water. So even a small shower delivers lots of water to our tank. I looked recently and the tank is still close enough to full, probably from the couple of showers we had a week ago.

I'd feel a lot more smug if I had planned this.

Friday, 9 April 2010

MaduraDocs 4.5 Released

I've just updated MaduraDocs. There are some minor cleanups in functionality but mostly tidy ups in the project structure making it easier to integrate into your ant projects. I'm now making use of ivyroundup which is a dedicated ivy repository. Previously I've used Maven repositories, which ivy can see okay, but they can be a bit inconsistent with naming, so it is easy to get duplicate jar files of different versions pulled into the project. ivyroundup is nicely 'moderated', and seems clean of such issues.

Before I say anymore about ivyroundup I should say just a little about Apache Ivy. Apache Ivy is a mechanism that manages dependencies in your project. You supply a list of products such as log4j, commons collections etc, that your project needs, plus one or more repositories to find them in. When requested ivy fetches the relevant jar files. But it also knows that those products need other products and so on so it fetches those too. That's a very brief overview, it does more but hopefully you get the idea. You can also easily build your own complete local ivy repository. This is normal for corporates who like the level of control. We do this at my day job.

The typical repository holds the dependency references as well as the artifacts (jar files). But not necessarily. There's an option to only store the dependency references and a url to find them, which can be elsewhere. So the ivyroundup repository doesn't have to consume a vast amount of space because it is essentially a bunch of xml files. That means you can pull a copy down to your local machine and mess about with it to add any missing bits you need. Then you attach the patch file with your changes to the helpful project owner who does some QA and then adds it in.

I've got all the dependencies sorted out now and they are in the ivyroundup repository. So that means the MaduraDocs project is somewhat smaller as well as easy to use. You just include it in your ivy dependencies and, during your ant build, you invoke a small ant file that gets pulled down from ivy (so ivy is not restricted to jars). This is described in detail in the docs which are, of course, generated by MaduraDocs.

Since I now have things so tidy I have uploaded the project to the SVN repository in googlecode.

Edit: I've moved this to a maven project on github. So it doesn't use ivy now.