Be careful if using Vaadin with Maven

As I'm getting more and more sick of bugs in JSF2 and RichFaces 4 and making painfully little headway, I thought I'd give Vaadin a go with a side project I'm fiddling with.

First impression, three hours in: The Vaadin developers don't use or get Maven, and while there's official Vaadin support for Maven their support is only superficial. The Vaadin Eclipse plugin only kind-of works with m2eclipse, scattering generated files throughout the src/ tree, putting library jars in src/main/webapp/WEB-INF/lib, adding jars directly to the Eclipse build path for the project, etc. It's not really a good maven citizen and needs plenty of encouragement to do the right thing, though it does seem to work once you've undone all the damage it does when enabled on a Maven project.

To clean up, you seem to need to:

• Enable the Vaadin facet in your project properties Project Facets section. Do not click on "Further configuration available..." or, if you do click it, make sure to uncheck "Create project template..." if you already have the vaadin servlet in your web.xml.

• 
  Check web.xml to make sure the Vaadin facet hasn't added a second copy of the vaadin servlet when it was enabled.


• Remove src/main/webapp/WEB-INF/lib and instead add a dependency on com.vaadin:vaadin:6.7.1


• Also add a dependency on com.google.gwt:gwt-user:2.3.0 because the vaadin artifact pom doesn't declare the dependency


• In your project properties, under java build path, remove the VAADIN_ entries from the Libraries tab. Otherwise you'll have those on the build path as well as the Maven-provided dependencies, which could get mismatched-versions-tastic in a hurry.


• Add src/main/webapp/VAADIN to your .gitignore; it contains generated code that's being dumped there not in target/.

In my first three hours with Vaadin, I reported seven bugs, though only three are more than cosmetic/trivial and are reproducible. Not a reassuring start, but I'm going to give it a chance because they're all related to Maven integration in the Eclipse plugin and to slightly dodgy artifact packaging. They might make a great tool and just not get Maven.

Downloading sources and JavaDoc for JBoss AS 7.1 using Maven

If you work in an IDE like NetBeans, or Eclipse with m2eclipse, you'll be used to having the sources and JavaDoc of Maven artifacts downloaded automatically. This usually works well.

Sometimes you want the sources for things that aren't direct dependencies though. I most often run into this when debugging an issue takes me into the guts of an application server. For example, when debugging yet another annoying Mojarra issue on JBoss AS 7.1 I needed sources for several unrelated chunks of the server. I didn't particularly want to build the server from scratch; I was interested in behavior on a release build. So I just asked Maven to download the dependency sources and JavaDoc for me:

$ mvn dependency:resolve -Dclassifier=javadoc
$ mvn dependency:sources

Of course, this'll only help you if library packagers have bothered to bundle the sources and JavaDoc of their library with their binary artifacts. This should be mandatory for upload into Central, but unfortunately isn't enforced or even strongly encouraged so artifacts are often missing sources. Maven can't (yet) use the SCM info to check them out for you, so you're stuck dealing with this mess yourself.

With the increasing profusion of complex dependencies in use in apps, we really need to make it mandatory to publish sources and JavaDoc to central alongside any binary artifacts for packages with open source licenses.