Changes in how dependencies are handled
As you all most likely know the plug-in will inject the required vaadin dependencies into the build so you can start developing with Vaadin without any whatsoever knowledge about what dependencies are needed. The plug-in by default takes care of that for you.
However, the way the dependencies were injected was never a supported solution and it had its flaws. One of the major flaws was that while it worked flawlessly if you were using the Gradle eclipse or idea plug-ins it didn't work so well if you were using the third party Eclipse or Idea Intellij Gradle integrations. They couldn't understand the way the dependencies were injected and often resulted in the dependencies not being visible inside the IDE without you specifically using the Gradle plug-ins and importing the project into the IDE in a certain way.
In Gradle 2.5 the support for default dependencies was added to allow plug-ins to do just what the Gradle Vaadin Plugin had previously done with its dependency injection. Moving to use the default dependencies rather than our own custom dependency injection it should allow IDE's to better understand that the plugin has added its own dependencies to the configuration.
Using the defaultDependencies has some side-effects you should be aware of if you are updating from 0.10 or below.
[Breaking change] Default dependencies work in such a way that they are only applied if there aren't any previous dependencies in the configuration.
This means that if you have been previously adding dependencies to the plugin provided configurations (vaadin-*) then only those dependencies you provide will be available for the plugin in that configuration. This can cause the plugin to complain about missing dependencies if you haven't made sure all needed dependencies are included in the configuration.
The upside is that you can now easily override any dependencies the plugin adds to the configurations by just defining your own. With great power comes great responsibility, if you touch the provided configurations then it is up to you to provide the correct dependencies.
Of course, if you don't like to have the plugin add any dependencies you can still set the
vaadin.manageDependencies = false and you will have to provide all the needed dependencies and configurations.
Support for multiple servers with vaadinRun
In previous versions of the plugin the only available server to run on has been Jetty. With Gradle Vaadin Plugin 0.11 a new server will be included, Payara.
Payara is an open source server heavily based on GlassFish Server Open Source Edition. With this new server you will be able to run applications that needs support Java EE technologies like EJB or CDI.
[Breaking change] Payara will replace Jetty as the default server to run on when using the vaadinRun task.
[New configuration option] The plugin will now introduce a new configuration option
vaadin.plugin.server which will allow you to select what server you want to run on.
But, if you don't need the new features, want a faster startup time or have already configured EJB/CDI with Weld or something else then you can still run on the same jetty as before by setting
vaadin.plugin.server = 'jetty'.
Support for Compass SASS
Since the beginning of Vaadin 7, Vaadin has included its own SASS compiler and the plugin has used that automatically to compile the themes with.
While the built-in compiler will suffice in 90% of the use-cases, many designers will opt for the Compass SASS compiler which provides more advanced features than the built-in Vaadin compiler does.
[New configuration option] The plugin will now provide you with the configuration option
vaadin.plugin.themeCompiler to select which SASS compiler to use. Setting
vaadin.plugin.themeCompiler = 'compass' will use the Compass SASS compiler instead of the built-in one.
However, there are some caveats with using the Compass SASS Compiler you should be aware of.
Secondly, Compass does not support providing themes from jar archives. This is specially important since Vaadin ships its Valo theme in the vaadin-themes jar. To workaround this the plugin will need to extract the themes from the jar into the build/themes folder to compile the theme.
Lastly, Compass is much slower than the Vaadin SASS Compiler to compile the themes. Combined with the two points above compiling the theme will take considerable more time than when using the Vaadin compiler.
So, when choosing which compiler to use you need to think carefully if the advanced features you gain with Compass SASS is really worth the performance loss in the build.
Improved integration testing of the plugin with Gradle TestKit
This is more a feature for those of us who develop the plugin itself.
Gradle 2.6 introduced a new feature, Gradle Test Kit which improves the way plugin developers can test their plugins.
Currently, the plugin project contains a few of these tests but in the future we will leverage these tests to make the plugin more stable in the future.
Minor other changes
vaadin.plugin.superDevModeoption was deprecated. It is from now always true as superDevMode is the only way currently to debug GWT code.
vaadin.plugin.jettyAutoRefreshoption was deprecated. This options is replaced by
How to get the snapshot version of 0.11
If you feel like you want to try out the new features in your project before 0.11 is released, you can do that by using the SNAPSHOT version of the plugin. Just be aware the the plugin currently is under heavy development and might still change before release.
Simply add the following to your build.gradle to apply the SNAPSHOT version of the plugin:
apply from: 'http://plugins.jasoft.fi/vaadin.plugin?version=0.11-SNAPSHOT'
If you find any bugs you can report them at https://github.com/johndevs/gradle-vaadin-plugin/issues