On another note, java related, I continue to write interfaces for simple beans (structs or data bearers). I consider this a good thing and the only downside I know of is that you write more code. Still, I wonder, are there other downsides that I do not know about?
Another random thought, what is the nicest way to name your interfaces and implementation classes? Howard Lewis Ship of hivemind & tapestry fame usually writes:
IServiceName
and the implementation class as ServiceName
Personally I prefer not to use the capital 'I' as a prefix. This reminds me of the horrible Hungarian notation. I usually write:
ServiceName
and the implementation class as ServiceNameImpl
Preferrably the implementation is in another java package from the interface:
xxx.yyy.zzz.Service
xxx.yyy.zzz.impl.ServiceImpl
However, I suspect that perhaps I shoudl really leave the package naming as is and remove the suffix Impl from the implementation. It is a pain to have the interface and the implementation to have the same name but different packages but somehting tells me that it really is "the right thing" © to do.
Maven
Here we have maven, the incredible build system that does everything automagically out-of-the-box. So, I have some small hobby-projects, they have been around for several years now. Some classes even date back to JDK 1.0 believe it or not. When I decided to release them as open source I thought that I needed a better build-system than building the separate things by hand every time I wanted a new version.
I started out using Ant and that is probably something you all know and hate, but it works.
Then I looked with envy on the cool websites that this tool called maven built. This was back in the Maven 1 days. So I started using that and I got my really cool websites, they looked exactly like the big boys websites. But that was for each separate project, I have dependencies between my projects and I wanted 1 website that linked to all sub-projects. Enter the "Reactor" plug-in. It soon became apparent that the documentation was a mess if at all existing. The multi-project problem had largely been ignored by maven developers and was close to impossible to handle.
So, back to Ant, I spent some long train rides messing with XSLT and soon had Ant-builds that could build sub-projects, collect information and generate 1 web for all projects. Then I found Ivy to manage my dependencies.
Ivy kicks some serious ass. It is difficult to get into, has some wierd XML to configure and the documentation could be better. But still, the documentation exists and is mostly correct and easy to read. Ivy "just works".
Enter Maven 2, this is where I'm today. Converting my beautiful, fully refactored Ant+Ivy build system to maven 2. This new version of maven handles sub-projects with ease., I haven't gotten around to see what kind of web sites it builds for those but I have confidence that they will look nice. Maven has some really strong ideas about how your directory layout should be. Still, the layout is logical and consistent so I can live with it. The advantage of following the maven layout is that maven "just works".
That is, until I wanted to create a distribution of my swing applications. I want to distribute a ZIP-archive with the following layout:
my-app.zip---myapp.jar
|-README.txt
|-NOTICE.txt
|-LICENSE.txt
|-/lib
|-myapp-dep1.jar
|-myapp-dep2.jar
So I looked at the assembly-plugin for maven 2. It has some more XML to configure what it is to do, there even is an XSD to help you with the XML.
The XSD has the wrong (I think) namespace. The documentation sucks, it links to the javadoc for the MavenArchiverConfig or some such class. The link is dead.
There is another mojo (maven plug-in) on codehaus that claims to build application dsitributions. But that generates startscripts. I do not need start-scripts. My application JAR is an executable and have a class path set in the manifest-thank you. Well, it has if I use the jar:jar plugin in maven. The assembly-plugin probably can do the same but the documentation is... well you get the idea.
So maven 2 lives by the 80-20 rule. It does 80 percent of the work, the rest simply can not be done unless you are one of the persons that wrote the damn thing or you spend more time looking at their source than it takes to write the Ant-scripts an configuring Ivy.
Maven does not zoom.