kafsemo.org

I'm enjoying Maven

Tuesday, 5 May, 2009 (#)

Like most Java developers, I have an opinion about Apache Maven. So far, I really like it. I wouldn’t try to build modular software without it and, even with its faults, I hope something very like it becomes a de facto standard.

Maven invites you to define your project as a named, versioned component that depends on other components. Maven assumes that your project follows a set of conventions for layout and, in return, you get the essential tasks: transitive dependencies are brought in and the compile time, test and runtime components are kept distinct. It will generate a unit test report, with test coverage, along with Javadoc and a packaged jar. There’s no rocket science in there, but copy-and-pasted Ant scripting goes away.

Other tasks use the dependencies; building up a distribution with all the other jars is simple. Update to more recent versions, run it again. Metadata can be used to track license consistency for a large project.

For me, the motivating feature is componentisation. It becomes very easy to split a large project into modules, and to make sure the dependencies are correct and consistent. It’s easy to build the whole thing from source or to take a module and build it against snapshots of a larger more stable framework. I feel a lot more comfortable with a clean, repeatable from-source build, and Maven really helps with that.

Of course, if you’ve used Maven you’ll have a few criticisms. If you’ve used it even semi-seriously, that’ll be a long list. Jason van Zyl mentions the path-paving model of development, which seems very appropriate in this case. I feel confident that the problems I see are fixable without a fundamental change of model. But yes, if you’re evangelising, don’t waste time claiming it’s perfect. Almost all the criticism you’ll hear is legitimate but not a deal-breaker. People are very attached to putting their source in a particular directory, just like some people still steer clear of Python for its white space.

Maven creates a fairly large infrastructure burden if it’s embraced fully for larger commercial deployments. Sonatype’s business model seems to be based around increasing demand for that infrastructure and then selling a solution for it. I like that, pace the usual suspicion about conflicts of interest between the free and commercial products from a company (their position is well stated). There’s some healthy debate over the relative merits of the repository implementations. All I can say is; Nexus worked well enough for me that I didn’t go looking for an alternative. Well done on the OOBE.

Maven, Ivy, OSGi and Project Jigsaw all touch on similar territory, and there are many projects to blend one with another. An open-minded approach to see what works and share the best ideas can only lead to a better product.

Release procedure notes

Wednesday, 29 April, 2009 (#)

Fixing bugs in old software can involve as much time remembering how to build and release as actually fixing bugs. A documented release process, even in brief, can make a great difference.

A while ago, I noticed that number of open source projects included documented release procedures. At first I was puzzled; only the person doing the release needs to know that, so why include it in the public project?

In fact, writing just a few simple notes for XML::Writer has been one of the best-value development practices I’ve ever followed. Yes, it’s just a reminder. I could have scripted those steps, too. But just writing down what to do, step by step, takes no more effort than running through those steps in the first place. Like all good documentation it makes you think as well. Is there a step that’s uncomfortably hard to communicate? Maybe that needs changing.

It helps others and, in a good way, facilitates forks. It’s always reassuring to come back to a project like that after a year or more and find all the steps written out. The busy developer you help may well be yourself.

Tools for iTunes Libraries

Monday, 10 November, 2008 (#)

I use iTunes on Windows to manage my music. That’s not an endorsement. iTunes is lock-in. It limits my options, but I like the features. It’s a compromise. There are very good reasons for not using it (“I loved iTunes until my iTunes database got corrupted”), but it’s been good enough for me. I can get at most of my data through a series of semi-public formats and documented APIs, and being saved the trouble of thinking about how to manage music is a feature in itself.

Then, I ran into a specific task - moving files from one drive to another, without losing any metadata. Doesn’t seem like it does that unless I let it choose where everything is stored. Now, I could throw away my metadata and start again, but that would be a shame. You can move tracks individually but that’s not really practical. Rebuilding from the XML version of the library throws a lot away. The COM API doesn’t expose file location as a writeable property.

The next option was to change the binary library myself. My starting point was brian d foy’s great documentation as part of the Mac::iTunes perl module. So the challenge was really whether I could figure out how to make the change before I resented iTunes enough to install something else.

It’s all checked in if you’d like to take a look (Java). I used the MoveMusic tool to make the change and it all seems to have worked. There are test cases in there, and the start of a more comprehensive data extractor. It’s all source. I can see a downside to productising something that will almost certainly break future versions of the library. (This was developed against 8.0.1.)

Some new features in iTunes appear to have their configuration in SQLite databases, which is a nice trend. (Closer look: SQL error: file is encrypted or is not a database. Oh, okay.)