Bean Validation Public Draft

Sounds like Bean Validation has been voted through the public draft stage. I've just finally managed to get my voluminous feedback into the appropriate hibernate forum after wading through the spec.

Mostly, it looks reasonable, although I'd prefer to skip the bootstrapping entirely, or alter it pretty significantly so that it doesn't remind me of Why I Hate Frameworks.

I'm also not sold that we really NEED a JSR for this until there are multiple competing and incompatible implementations that take on validation seriously, which isn't currently true, IMO. Although I've used Hibernate Validator before, I'm not sure one implementation justifies a JSR.

But anyway.

Releasing Multi-Module Maven Projects

When you're doing a release using the Maven release plugin, Maven likes to ask you what version you'd like to release and what the version should be after the release.  For final releases, the defaults are often sensible, and you can accept them by turning on batch mode.  For interim releases, they usually aren't.

When you're doing this with a single project or a project with a very small number of modules, answering those questions for each module isn't such a big deal.  When you're working with a project with a larger number of modules, this gets very tedious very quickly.  The batch mode example  suggests that you can pre-specify the release version for each module, but it fails to highlight the property that a friend of mine just pointed out: autoVersionSubmodules.  That'll save me a lot of pain in the future.

Google App Engine Roadmap

The Google AppEngine roadmap shows a lot of promise; it'll significantly increase the sophistication of the applications that can be delivered using AppEngine. It's still true that it's hard to justify building a real application in an environment you don't control and can't easily duplicate, but it's nice to see solution gaining maturity.

If Google offered an open-source production environment -- not necessarily anything on Google's scale, but something that someone could deploy to at least a single server, or possibly a cluster of their own, of reasonable production quality, that would reduce the lock-in to the point that someone could conceive of building their own applications on AppEngine.

Eclipse 3.5 M4: Never Join Lines

As of Eclipse 3.5 M4, the formatter has an option to "Never Join Lines" or preserve user line breaks.

Finally.

I've gotta say, that's been one of my most consistent irritations with the Eclipse formatter ever since I started using the damn thing, something that IntelliJ IDEA did farther back than I can remember. I'm really looking forward to that.

While I'm on the subject:

• Eclipse 3.5 M5
• The ability to quickly paste a site in to install rather than having to manage your sites seems like a good addition, in keeping with how people actually want to use the system.
• SWT/Cocoa leaving experimental stage, that's good news for Apple fans.
  
• Eclipse 3.5 M4
• Preserving line breaks.
  
• Eclipse 3.5 M3
• The equals/hashcode compiler warning seems like a good idea.
• The extension point for clean-ups seems like something that could result in some useful additions given time.
  
• Eclipse 3.5.M2
• Eclipse 3.5.M1
• Support for ${inheritDoc} in the Javadoc view is great.
  
• Comparing word documents is the sort of feature I hope I don't need to use, but will probably end up using at some point anyway.
• A warning for comparing identical expressions seems valuable.

All in all, there's nothing here that seems critical, but lots of useful polish, and the formatter one alone is enough to warrant the ugprade. I'll have to take a look at the larger release train as well to see what else is coming.

That said, I have to say, I'm disappointed with 3.4 release -- I've had more problems with it than with previous versions, it feels like the quality's dropped off a little.