Trying to update Grails Vaadin plugin to Vaadin 7

I am quite in a shock. I have tried to update grails-vaadin plugin so I could use the new version of Vaadin 7.0.0alfa3 together with Grails 2.1.0. But what a surprise... alfa3 contains a bit more classes than previous version and it makes it imposible to integrate Vaadin 7.0.0 alfa3 with Grails 2.1.0. 

Have a look how size of Vaadin jars increased...

What does it mean. When I try to add com.vaadin:vaadin:7.0.0.alpha3 as dependency then Grails fails to load with the following error: 

Error Interactive mode exited with error: loader constraint violation: when resolving method "javax.xml.parsers.SAXParser.getXMLReader()Lorg/xml/sax/XMLReader;" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the current class, groovy/util/XmlSlurper, and the class loader (instance of <bootloader>) for resolved class, javax/xml/parsers/SAXParser, have different Class objects for the type org/xml/sax/XMLReader used in the signature.

I have already complained about it http://dev.vaadin.com/ticket/9180. Let's see what happens with the next releases. I still hope it is a kind of a bug or bad joke that there are so many libraries included in the package. 

Here you can find working version of Vaadin 7 (alfa2) for Grails (it is still experimental version, but it worked for few people already): https://github.com/ondrej-kvasnovsky/grails-vaadin-plugin/downloads.

Hints for Grails app running on Cloudbees

Here are my most used commands I use during development and deployment of Grails application which is running on Cloudbees.

Dependencies when changing BuildConfig 

1. It happens quite usually - you add a new dependency to BuildConfig and it is not visible in your code. This helps to load it. I am also using --include-source option to get jars (because I might be wondering what code is behind).
   grails refresh-dependencies --include-source

Testing during development

1. I am not using integration tests. The are two reasons why. First, it is possible to mock everything. Second, integration tests requires context and it is time consuming when starting it up. 
   dev test-app unit:
2. I usually run only one specific unit test when developing a feature.
   dev test-app unit: UserServiceTests
3. From time to time I need to have more applications running at the same time (e.g. when doing an integration between client application, admin application and some web services). 
   dev run-app -Dserver.port=8080

Validation before deploying war into the production

1. At first, run all the tests. E.g. my web services written in Grails have 95% line coverage, applications about 80%. So I am quite confident when deploying it to production. 
   test-app
2. Simulate running the war on local machine. Running application by run-war might uncover some issues which could occur during deployment of war on cloud. It can happen that application is running well when it is started by run-app but it fails during deployment (which causes your production app is not available). 
   run-war
3. After the steps above are without problems then I make a production war file.
   prod war
4. It is necessary to install CloudBees SDK so the applications can be deployed from command line. 
   bees app:deploy myapp.war -a myaccount/myapplication
5. This is how to restart application from command line... it is quite handy. bees app:restart myaccount/myapplication