Vaadin appears a great apprach for cost effective front and backend development. But what about all the other bits ? The IDE EcoSystem destroys the beauty and economics of Vaadin. Sort of a lavish house in the middle of a polluted swamp.
The time, effort, confusion and complexity of so-called Vaadin “helper” tools is astonishing. Loading another standard Vaadin demo into Eclipse, for example, is guaranteed to break other unrelated Eclipse Vaadin Maven projects. An unexpected change in a version number causes the Build to FAIL and requires zero-value-adding effort to isolate, diagnose and repair. The eco-system is very BRITTLE.
Given that all these tools/components must
work together , why is there no documentation on them
all together in one document? Even a simple explanation of seemingly conflicting things like
Maven Plug-Ins vs
Maven for Eclipse would be a start.
If we are all wasting the same time as our team then it would seem worthwhile for those with the wisdom to document some reusable configurations and archetype combinations that are all guaranteed to work. … OR … Better still, a full Vaadin Project Q&A-Style initialiser, like the SPRING INITIALIZR to get all the fundamental (and BRITTLE) parts organised correctly, from the start. The Book of Vaadin steps through specific eco-system use cases but assumes all these bits are already installed and configured wisely.
So excuse the rant, I feel a
little better, but this cannot be an isolated observation. Short of redoing a Computer Science Degree, what might be the single best source of knowledge and wisdom, so as to continue with Vaadin?
I am not sure exactly what your issues are, but I was able to get a full spring/vaadin app up and running using maven in a matter of minutes. Even imported it into InjelliJ no problem.
Step 1. Install Maven on your system.
Step 2. Go
here and configure what you want in your app. At least make sure to include Vaadin as a dependency.
Step 3. Extract the generated project and import into IntelliJ.
Step 4. Build the application and hit the play button.
I am not sure how to make it even easier then the steps above. I guess you don’t really need to import the project into an IDE, you could build and run the app from the commandline if you wanted to get the app up and running faster.
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 …
I’m not quite sure whats being difficult with Vaadin in your case. Sounds more like Maven is not your kind of thing. I must confess it wasn’t for me neither some years ago, but once you get used to it, you recognize the value of the tool. But this is not specific to Vaadin.
Vaadin in the end is a bunch of JARs that you can drop into any Java project. It just happens that nowadays, Maven seems to be one of the best tools for that. The same goes for JPA, Spring, Shiro, and others. You just have to include the JAR (as a element, if Maven) and start using the API of the library.
Regarding IDEs, for most of the projects I create (and trust me, I’m creating several new projects per month using Vaadin), I use either a Maven archetype or the Spring Initializer and I found it quite simple to get a Vaadin application up and running on any IDE in one or two minutes. But of course, I’ve been using Vaadin and Maven for several years already, so I’d really like to understand you better. I’d be even happy to have a chat with you regarding this if you are up for it
I’ve been following Vaadin for almost 10 years now. The “fragility” you feel, I believe comes from a long history of the vaadin team being actually focused on a reduced set of tools (their eclipse set), while adding other stuff via maven to appeal to other developers (those not gravitating around their choice of IDE, web server, build system, etc). I’ve found often over the years when I test the state of vaadin, every time I’ve checked under the hood it has been pretty evident that there’s a core “whole-heartedly supported” set of tools, and then there’s the rest.
They have evolved: There was a time when Spring was part of “the rest”, also they now have a Designer for IntelliJ.
All in all, it’s not really a bad arrangement for what in the end is a commercially friendly open source software of good quality. Like you, I don’t think the rough edges are an attempt to drive the support selling business, but more of a telling sign of the actual size of the organization behind vaadin, and the technology focus of their existing and previous customers.
Perhaps you could try what I do: I have 2 IDE projects: my “widgetset compilator project”, which uses maven, imports/upgrades dependencies, compiles widgetsets, and is only meant to produce a set of .jar and javadc files for the second project. That second project is where I write my code, in my IDE of choice (intelliJ), using DCEVM for hot redeploy, manually adding all the vaadin jars and widgetsets compiled by the other project, integrating my choice app server the way I choose and trust (not that maven jetty plugin), and my IOC framework of choice (Guice or Spring). This way I get to work with the tools I like the way I like them, and still use vaadin without depending too much on their preferred toolset for build/ide/appserver/ioc/etc.
Vaadin tool chain embraces Maven. I would definitely say that Maven support comes first and then IDE support comes second. I’m not sure the people from Vaadin Inc would phrase it exactly like that but that’s how I see it … and it is a very wise choice.
When I first started learning Maven many years ago my IDE was Eclipse. It was really a nightmare at the time using Maven from inside Eclipse. I blamed Maven for this. It was only years later I understood what the real problem was: The IDE didn’t actually fully embrace Maven, it was more of an add-on. Much later I joined teams using IntelliJ and NetBeans and discovered that this need not be so. For example in NetBeans (and in IntelliJ, I believe) the POM is also the IDE’s project definition. The IDE doesn’t keep its own parallel definition of the project. The POM is God, so to speak. Only from that point onwards could I fully appreciate Maven.
Now, Eclipse being a great IDE I’m sure this has been fixed somehow and Maven is now a first-class citizen in the IDE. However it still seems strange to me that Maven support is an add-on that needs to be installed and can have version inconsistencies with the rest of IDE, etc. Not detracting from Eclipse’s other virtues the fact remains that IntelliJ and NetBeans users don’t have to think about Maven support. It is just there and it works. You can’t even obtain a distribution of those IDEs
without Maven. The Vaadin plugin for those IDEs really doesn’t do anything else than to act as shortcuts for some Maven commands. I could easily live without the IDE plugin although I value the shortcuts it presents. Now, I’m saying this because I suspect the Vaadin plugin for Eclipse is a bit more complex (because it needs to be) and therefore has more potential to have bugs.
My point here is that if either you or your IDE is not fully friends with Maven then Vaadin builds will seem like a strange beast to you.
So when you ask what to do: Embrace the Maven beast. That’s the best advice I can give.
We had a hunch that there were some awkward Maven / Toolchain / Vaadin / IDE integration issues but didn’t have the deep experience to isolate and validate that hunch. We are delighted with Vaadin but struggle to cost justify the necessary ecosystem.
Seems like IntelliJ can untangle some of our confusion. Shall post our conclusions sometime soon.
