Well my issues are somewhat high level. It’s not necessarily about any one configuration or use-case but rather the expectation that every programmer must have an intimate knowledge of all the support tools that surround Vaadin.
Step 1. Install Maven … where, how, why, then integrate with Eclipse, edit POM.XML to reflect the current state of the project, lookup all version numbers and transcribe them to the POM, update Environment Variables and other properties to find Java and Maven and Jetty, then repeat for every other component JPA, Spring, Shiro etc. We can’t just ignore these steps because we each happen to know one or two setups that work.
Sure we can revert to command lines and our own shell scripts but … it’s a new millenium. We too can get a range of simple , specific configs to work as above but as soon as there’s a new *.java file or, we want to use another web server, things fall apart. We are no longer programming but troubleshooting.
Maybe this is a by-product of the Vaadin business model. A cynical view might be … Build something clever, useful and interesting but keep enough of the technical details back to fuel the support driven revenue model. I happen to think otherwise. I’m sure many would just like to see a simpler approach to the “eco-system”. There’s still plenty of consulting wisdom left to pay for …