Flyway Jasypt Gradle

By the way, if you happen to be using Flyway ( for your migrations, Gradle ( for your build/tasks and Jasypt ( for encryption, here’s an example Gradle task for tying the three together.

flyway {
    StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
    encryptor.setPassword('testtest'); //<-- your Jasypt password can come from anywhere.  Hopefully somewhere more secure than this.

    def flywayFile = file('')

    Properties flywayProps = new EncryptableProperties(encryptor)
    flywayFile.withInputStream { stream ->

    url = flywayProps.url
    user = flywayProps.username
    password = flywayProps.password

    initOnMigrate = true

Part 1: Getting Started (again): Build A Web App With Spring Boot

As the latest in a long line of enhancement to the Spring framework aimed at eliminating boilerplate code and decreasing the time spent by developers setting up a new project, Spring Boot serves its purpose well. In this installment, I’ll walk through getting a project off the ground, rehashing much of what is covered in the first Spring-Boot starter guide on the site. This will serve as the basis for upcoming installments. In this series, I’ll be using Java 1.7, Gradle 1.11, and Spring Boot 1.0.1.

Setting Up

There are Spring Boot starter versions of several different projects: web projects, data projects, integration projects, etc. Here we’ll be starting with the Spring Boot web project.

The first step is configuring your project’s directory structure. Spring Boot, whether you’re using Gradle or Maven, both follow the classic convention for directory naming and source structure. Create an example project using the structure below, substituting values in square brackets with your own:


In the root of our project, we’ll create a new build.gradle file:


buildscript {
    repositories {
        maven { url "" }
    dependencies {

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'spring-boot'

jar {
    baseName = 'getting-started'
    version =  '0.1.0'

repositories {
    maven { url "" }

dependencies {


task wrapper(type: Wrapper) {
    gradleVersion = '1.11'

Several items to mention here:

The ‘buildscript’ closure sets up the build itself. This is where the plugins used by the build are declared, along with the repositories in which they can be found.

Following that, there are several plugin applications.

  • The java plugin provides the basic tasks related to a simple java project – compiling and packaging, among others.
  • The eclipse and idea plugins allow project files to be created for eclipse and Intellij, respectively.
  • The spring-boot plugin contains tasks that build executable jars and execute them using embedded tomcat using tasks
    like ‘bootRun’, which we’ll use often in these tutorials.

Next the ‘repositories’ closure is used to declare where the project’s dependencies will be found.

After that, there is a ‘dependencies’ closure that contains the jars required by the project

Last, there is a standard gradle pattern – the task wrapper – which is used to enforce the version of gradle being used on the project, as well as allow easy execution of the build by users who do not have gradle installed. More information on that found here.

Application Configuration

In the source root of our project ([project-name]/src/main/java/[package-name]), create a file called ‘’. This file mirrors the one found in the first Spring-Boot tutorial, but since it serves as the foundation for upcoming tutorial sections, I’ll call out a few things already explained on the site:


package com.rodenbostel.sample;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

public class Application {

    public static void main(String[] args) {, args);


You’ll notice two major components of this file: the annotations, and the main method.

The annotations are marker interfaces used to alert the framework that this is a Spring config file (@Configuration), that you’d like to scan for beans to load in the current and child packages (@ComponentScan) and that you’d like to use auto configuration settings (@EnableAutoConfiguration). Auto configuration in Spring Boot takes the concept of convention over configuration to an almost Rails or Grails-like level. It provides basic configuration of an application – where to find properties files, how properties files are named when using Spring Profiles, configuration a DispatcherServlet (note the lack of web.xml), and much more. It is worth it to look further into what auto configuration is providing to insure your application does not conflict with it, especially if you’re planning on deploying to containers that also provide libraries on the class path by default (I’m looking at you, Websphere).

The main method simply allows the application to be executed from the command line. This includes the startup of your embedded container (in our case, Tomcat). It’s worth mentioning here that the return type of is an ApplicationContext object which can be further manipulated.

Creating a Controller

Again using the similar source to that of the Spring Boot demos on the site, we’ll begin developing our app using a sample controller configuration as a RestController to verify our app is functioning correctly. In our source root ([project-name]/src/main/java/[package-name]), create a file called ‘’.


package com.rodenbostel.sample;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

public class SampleController {

    public String index() {
        return "Greetings from Spring Boot!";


Here we are using constructs familiar since Spring MVC 3.5-ish. The RestController interface declares just that – a RESTful controller. This controller will return strings instead of views by default. The RequestMapping annotation on the only method in this class should be familiar, too. This calls for the controller to respond to requests at “/“ by executing the index() method. In this case, we’re responding with a simple String.


For this introduction, and the tutorials that follow, I’ll be using ‘gradle bootRun’ to execute the app. Upon executing ‘gradle bootRun’, in a browser, visit ‘http://localhost:8080/’, and admire you’re work. You should be looking at a simple string: ‘Greetings from Spring Boot!’.
Screen Shot 2014-04-07 at 9.21.09 PM

Preparing for Part 2

Again, this post re-hashed most of what is found on the site on the same topic. I hope this has included some additional insight that will help get you started. Since this will be the foundation for Parts 2 and beyond, the code up to this point can be found on Github. The next installment will start where this post left off. Check back soon for the next installment: Adding views using Thymeleaf.

SpringOne2GX, Day 3 Recap

Two great demos in the morning regarding Gradle, by it’s author, Hans Docktor. Gradle is something I’d heard about frequently, but never bothered to look into thinking that I didn’t need to learn another way to build until it was necessary. Combining the declarative nature of a DSL with the scripting capabilities of Groovy, Gradle looks to be a “next generation” build tool. Familiar constructs exist – job, task, etc – but each of those constructs has properties that can be inspected, and the DSL itself can be easily extended to meet an organization’s need. Since the Ant jars are packed with Gradle, it looks like Gradle should have easier inroads into the enterprise than other new build technologies. Any task or all of the build can be written using Gradle, which would allow for a migration approach as opposed to a conversion. The demos themselves were smooth and engaging with no technical hiccups. Really good stuff.

The last talk of the conference was a demo of Daisy CMS Grails. Like a few other talks/demos, I learned more about the subject itself (CMSs) rather than the technology that was the subject of the talk.

In all, a good conference. The quality of content in the talks varied greatly. Some were demos, some were presentations, and others seemed like they were thrown together at the last minute. The good content was great, and the not-so-good content, well, was not-so-good. Although I’m sure the pub crawl was fun, I think the conference could have fit into two days had the lower quality material been removed. I came away with a few exciting things to look into and a new appreciation for the Spring/Groovy community.