Half a Year of Maven 2: An experience of the awkward kind

We're using Maven 2 now for all new projects. At the highest level I can summarize our experience as:

1. The concepts behind Maven are sound and amazingly useful.
2. The implementation is just about usable - no show-stoppers anymore, but lots and lots of little, annoying bugs and surprising gotchas
3. The documentation is sloppy.

The really funny thing is, how point 1. still by far outweighs the shortcomings 2. and 3 when it comes to the question "Was it worth it, after all?".

So what made it useful, after all?

• First of all, it gives your builds a uniformity and completeness (JavaDocs, HiveDocs, PMD, CPD, ...) that would be difficult to achieve otherwise without having a dedicated, organization-wide build-manager (as a real person:).
• Secondly, it facilitates re-use by making doing the right things easier than the wrong ones. Having cleanly specified dependencies referring to specific binary versions of jars makes a bigger difference than you might think without trying. And being able to inherit a big part of your build-setup from an org-wide POM (the ant project descriptor) is a real killer feature. Together with archetypes this makes the overhead for starting a new library-module really negligable.
  

Enough praise. The downside is, there is still way enough room for maven-improvement wishes for the new year. Too many things just make - sorry - too sloppy an impression for a project which is purportedly backed by a professional org (Mergere). Some of the issues I remember are:

• Docs: One of the benefits of Maven should be good consistent docs. Ever searched for reference docs on the site-descriptor site.xml? Google the mailing-lists. Wondering how to generate standard plugin-documentation? Don't bother with the docs. Just have a look at the POM's of existing modules. Looking for core API-docs? You'll find something like this
• The SCM / release plugin claims to support DOS'ish CVS-pathes (D:\...) - in the report it works, but the release:prepare fails.
  
• Special characters in the generated docs don't work. E.g. german locale.
  
• Want to create a repo-bundle for a multi-module project? Doesn't work.
• In a Mojo you can inject things into private fields - If a superclass happens to have a private field of the same name the injection fails silently.

So, after all, a great tool with a great amount of small issues to work on. Please, Maven guys, put some effort in finishing off the little bugs - and thanks for a useful tool.

New Version of hivedoc-plugin for HiveMind

Since some people seem to use it, I've updated my hivedoc-plugin to version 1.0.1 . Notable changes are:

• Support for custom resource root directories
• Backport to Java 1.4
• proper plugin-docs

The new version should show up on the central Maven 2 repo soon. If you need it before that, here's the repo-bundle.

hivedoc-plugin generates Maven 2 docs for HiveMind descriptors

If you're using HiveMind and Maven 2, generating docs for your HiveMind descriptors is now really quick and simple.
Find the docs under http://marcus-schulte.ch/hivedoc-plugin/.

Honeycomb now comes with a Maven2 archetype for Tapestry/Hibernate based web-apps.

Version 0.3.3 of Honeycomb is released.
Honeycomb provides an easy integration for Tapestry and Hibernate. Its distinguishing key feature is session-per-conversation support.
The main changes in this release are:

• re-structuring into 4 libraries replaced the templates for the Core/Webapp projects with maven archetypes. Maven users get started without manual downloads.
  
• Fixed rollback on RedirectException.
  
• Fixed possible concurrency issue in cross-request service-model
  
• Fixed: Removed dangerous loophole allowing a conversation to survive a rollback triggered by an exception.
  
• Cleaned up HiveMind descriptors and moved them into the lib-modules.
  
• added a Watch component to the tap-lib (calls a listener when a property has changed in a submit)
  

The Return of the Database - who needs more "middleware"?

Maybe it's just my organization's policy of giving its developers relatively free access to db's while, at the same time, putting lots of administrative hurdles and hurdle-like administrators between them and the app-server. But it's really amazing how little there is that you can't get done nicely with a sturdy db and a decent servlet-container (at most).
Example: For some time I thought a nice event-driven architecture I was planning would require some serious investment (of money and effort) into some sort of enterprisy message-bus, and, of course, then you'd have at least 2 transactional resources to keep synchronised, crying for some "serious" app-server... When I suddenly asked myself, why the hell one ta-resource, the database wasn't enough. And it is, I think. For small-scale integration tasks, where we can control the deployment of all involved systems, business components shared across applications and working on the same database will do just fine. For more difficult tasks requiring some more decoupling there's stuff like Oracle Advanced Queuing - which can be used as a JMS implementation backed, ultimately, by db-tables. Similar things should be easy to implement on any db.
And the best thing: only one ta-resource, only jdbc, no need for two-phase-commit, old Tomcat will do.

KickStart is now Honeycomb, release 0.3 out

Kickstart has moved from SourceForge to JavaForge, and it's changed its name to Honeycomb (alluding to the central role that HiveMind plays in it). Honeycomb integrates Tapestry with Hibernate for painless full-stack web-dev-support.
New features comprise

• A hibernate DataSqueezer


• Pluggable Audit-Trail via hibernate interceptor


• Support for session per request pattern via simple config switch.

With Kickstart 0.2 Tapestry supports the hibernate session-per-conversation pattern out of the box

I've uploaded a new release of KickStart. Improvements are:

• Full support for the hibernate-session-per-conversation pattern. See hibernate.org for more.


• fixed wrong unsaved-value-mapping