Vaadin + Intellij community edition.

Hey,

I’ve written a Vaadin app in eclipse before to great satisfaction. However recently I tried out intellij and ended up deciding to stick with it. Now I want to build another Vaadin app, this time in intellij.

I’m a hobbyist and a new father. I do not have 500 euro’s to spare for the ultimate edition.
I have tried the gradle route and gotten a simple app running. But intellij is so poorly integrated with it that running, stopping, restarting are all a chore.

I presume others are in the same situation. How have you solved it and are there any sample projects that I can pick through to learn the tricks?

Kind regards
Wouter

I add all the jars manually to projects that use vaadin - in NetBeans.
You could do the same with JetBrains …

I have, and this allows me to compile the code and build a war file. But vaadin works in combination with a webserver like tomcat, and I find that the integration with tomcat in the community edition is lacking.

How do you run your app in tomcat in your development environment?

In Netbeans, you can define the server in the menu Tools | Servers.
Then just hit the ‘Run’ or ‘Debug’ icon.
Not sure if JetBrains has this server menu.
. . .
Otherwise, you can deploy to Tomcat.
http://localhost:8080/

Then go to “Manager App”, Login to Tomcat.
Browse for the WAR and install it.

I’m afraid the server menu isn’t there in the community edition.

And I could deploy war’s to tomcat. But that’s not the short edit/compile/debug cycle I was hoping for.

Thank you kindly for taking the time to suggest some answers though :slight_smile:

From a quick google search it sounds like your only option would be to use maven in the community edition:

http://stackoverflow.com/questions/22047860/tomcat-in-intellij-idea-community-edition

I have found that solution. And tried gradle’s variant, with a vaadin plugin which does the exact same thing I have been able to compile and run a development server. I presume Maven can get the same job done.

The problem isn’t that I can’t get it to run, the problem is that the end result is so poorly integrated with the IDE that the Edit/Compile/Debug cycle becomes laborious. Under eclipse it was a matter of changing code, saving the code, switching to the browser and testing the code. That same result would be the ideal situation for me.

Now I get files that can’t be overwritten for being in use. The intellij compiles are apparently not compatible with the gradle compiles because if I try a compile from intellij things stop working I need to clear the project and recompile a few times before it works again.

I was hoping that someone had done the same thing in intellij and could give me some pointers on getting results without me having to use a command line to compile and build my code.

Thanks everyone for your input…
I finally found a solution.
Attached are my notes for the next person who’d like to do the same.

Short summary:
I used gradle vaadin and idea plugins.
Gradle build includes tomcat + embed sources. and a resource dir copy task.
A public static void main was written to start tomcat with the vaadin servlet passing it the required ui parameter.

ctrl-f9 rebuild works, and debugging works.

IT’s not perfect, touch the gradle file and intellij will mess up it’s dependencies, which can easily be fixed by running the idea task. But it smarts a bit…

Kind regards.
21076.html (36.4 KB)

This thread forced me to write a short manual about the subject. Now it’s in Vaadin blog

https://vaadin.com/blog/-/blogs/vaadin-and-intellij-idea-community-edition

Awesome Ilia. I’m sure that’ll come in handy. Unfortunately your usage of a maven archetype stops me as a gradle user from following your steps. It’d be interesting to setup a similar blog for gradle users… :wink:

There is a gradle based vaadin plugin… It works for eclipse. However, it does not work for intellij. It attached dependencies in such a way that intellij fails to pick up on them. This caused a lot of errors in idea. The idea plugin fixes that to some degree in that it rebuilds your idea project files adding all the appropriate dependencies. But that is flawed in the sense that I could not get it to work for multiple modules and the dependencies tended to ‘break’ a lot…

So I ended up dropping the vaadin gradle plugin. Here’s my current gradle file for those who are interested:

Also see the html file I attached in an earlier message, it describes how to setup your initial project…

apply plugin: ‘java’
// Application plugin allows you to run the program from command line. Consider it optional…
apply plugin: ‘application’
// The war plugin is required in case you want to deploy your project.
apply plugin: ‘war’

// This line tells the application plugin what main class to run.
mainClassName = “willow.hearthbonds.Startup”

repositories {
mavenCentral()
}

dependencies {
testCompile group: ‘junit’, name: ‘junit’, version: ‘4.11’

// Multi project support works... Yay... Needless to say, you can leave this out.
compile project(':kernel')

// I think these are the vaadin libraries you need at a bare minimum.
compile 'com.vaadin:vaadin-server:7.5.4'
compile 'com.vaadin:vaadin-client:7.5.4'
compile 'com.vaadin:vaadin-themes:7.5.4'
compile 'com.vaadin:vaadin-client-compiled:7.5.4'

// These are required to run the servlet in an embedded environment.
compile 'org.apache.tomcat:tomcat-catalina:7.0.41'
compile 'org.apache.tomcat:tomcat-util:7.0.41'
compile 'org.apache.tomcat.embed:tomcat-embed-core:7.0.41'

// Additional dependencies go here...

}

// For some reason intellij refuses to copy resources there is bound to be a way to get it to work, but I eventually gave up and just put this in side stepping the issue…
task copyResources(type: Copy) {
from “${projectDir}/src/main/webapp”
into “${buildDir}/classes/main”
}
processResources.dependsOn copyResources

I’m not a gradle expert. So this file can probably be improved upon. But it will get your vaadin project to work under intellij CE…

Running via embedded server goes a little something like this: Note the vaadin specific addInitParameter, that one had me struggling for a bit.

public static void main(final String args) throws IOException, LifecycleException, URISyntaxException {
Tomcat tomcat = new Tomcat();
tomcat.setPort(8080);

File base = new File(System.getProperty(“java.io.tmpdir”));
Context rootCtx = tomcat.addContext(“/app”, base.getAbsolutePath());
Wrapper wrapper = Tomcat.addServlet(rootCtx, “myApp”, new HeartbondsServlet());
wrapper.addInitParameter(“ui”, “willow.heartbonds.HeartbondsUI”);

rootCtx.addServletMapping(“/*”, “myApp”);

tomcat.start();
Desktop.getDesktop().browse(new URI(“http://localhost:8080/app”));
tomcat.getServer().await();
}

Hi Wouter S.,

Sorry to hear that the Gradle Vaadin Plugin didn’t work for you in Intellij.

As you say Intellij currently has a problem handling the way the plugin injects the dependencies and one way to fix that is to use the Gradle Idea plugin to generate the idea project with. Whenever you add a new dependency to the project you need to run “gradle idea” again and refresh the idea workspace so the new dependencies are recognized by Intellij.

But, there is also another solution. the Gradle Vaadin Plugin allows you to define the dependencies yourself instead of having the plugin inject them. To do that you need to add the following to your plugin configuration:

vaadin { manageDependencies = false manageRepositories = false } By defining that the Gradle Vaadin Plugin won’t inject anything, and you can provide the Vaadin dependencies manually just as you have done you your example.

Thank you John for your addition…

It would allow to use the additional features offered by the vaadin plugin. Such as the debugger tools the theme/widgetset compiler and creating the project.

I will add your suggestions to my gradle files… I have not stumbled on problems yet. But I was a bit worried, especially where those themes/widgetsets were concerned.

This would make the final result a lot more easy than the solution I came to…

Might I humbly suggest you add this as a tip to your github page? Maybe people will come to this post via google. But the github page is much more prominent. And this tip could end up saving people some headache.