Project structure

The structure of the project is fairly straightforward, but big enough to demonstrate some of the features that gradle has to offer. It consists of two modules:

• App
• Web-ui

We are creating an Axonframework sample, the app contains the command handling and for now the query part as well. The web-ui contains the spring mvc app with the controllers and the authentication using the spring-security framework. For now we make use of an in memory database and we want to be able to start the application without a lot of hassle. Using jetty in this case.

The modules have some shared dependencies for testing and logging. We also want to centralize the definition of some dependency versions.

Multi module gradle build

Gradle was build with multi module support from the start. So what do you need to create a multi-module build. We need a settings.gradle that defines the available modules. Next to that we need the main build.gradle as well as the modules build.gradle. Oke you can do without the per module configuration, but in my case that was not the intention. Let us focus first on the main build.gradle.

Main build.gradle

The main build.gradle is used to define some of the versions of the dependencies. The following code block shows the complete script.

axonVersion = "0.6"
springVersion = "3.0.4.RELEASE"
springSecurityVersion = "3.0.3.RELEASE"
slf4jVersion = "1.5.8"
sourceCompatibility = 1.6

subprojects {
    apply plugin: 'java'

    configurations {
        all*.exclude group: "commons-logging", module: "commons-logging"
    }

    repositories {
        mavenCentral()
    }

    dependencies {
        compile "org.slf4j:jcl-over-slf4j:$slf4jVersion",
                "org.slf4j:jul-to-slf4j:$slf4jVersion"
        runtime "org.slf4j:slf4j-log4j12:$slf4jVersion"

        compile("log4j:log4j:1.2.15") {
            exclude group: "com.sun.jdmk", module: "jmxtools"
            exclude group: "com.sun.jmx", module: "jmxri"
            exclude group: "javax.mail", module: "mail"
            exclude group: "javax.jms", module: "jms"
        }

        testCompile 'junit:junit:4.7'
    }

    group = 'org.axonframework.samples.trader'
    version = '1.0-SNAPSHOT'
    sourceCompatibility = 1.6
}

As you can see, the script starts with the definition of the versions of dependencies. Than the script contains information for all the subprojects. You see we define the java plugin for all subprojects. Next to that the repositories and the dependencies are defined. Have a look at the mechanism to exclude transitive dependencies. For log4j we explicitly exclude some transitive dependencies. We also use a mechanism to exclude commons-logging from the complete build. Using the configurations hook we exclude it for all phases.

Finally we also define the group, version and source compatibility in the build configuration.

That is it, the following code block shows the required settings.gradle and after that we move on with the build.gradle of the app and web-ui subprojects.

include "app", "web-ui"

Subprojects build.gradle

The build.gradle for the app project is almost to easy to show. But I promised I would, so here we go:

dependencies {
    compile "org.axonframework:axon-core:$axonVersion"

    compile "org.hibernate:hibernate-entitymanager:3.4.0.GA",
            "c3p0:c3p0:0.9.1",
            "org.hsqldb:hsqldb:1.8.0.10"

    compile "org.springframework:spring-tx:$springVersion",
            "org.springframework:spring-orm:$springVersion",
            "org.springframework:spring-jdbc:$springVersion"

    compile "com.thoughtworks.xstream:xstream:1.3.1"

    testCompile "org.axonframework:axon-test:$axonVersion"
}

The configuration only contains dependencies. I would like to be able to simplify the dependencies on the spring projects. Would be nice if I could group them somehow, like:

compile group:”org.springframework”, version:”$springVersion”, module:["spring-webmvc", "spring-aop"]

But the build config looks pretty clean. Now we move on to the creation of the war for the web project.

apply plugin: 'war'

dependencies {
    compile project(':app')

    compile "org.springframework:spring-webmvc:$springVersion",
            "org.springframework:spring-aop:$springVersion"

    compile "org.springframework.security:spring-security-web:$springSecurityVersion",
            "org.springframework.security:spring-security-config:$springSecurityVersion"

    compile "javax.validation:validation-api:1.0.0.GA",
            "org.hibernate:hibernate-validator:4.0.2.GA"

    runtime "javax.servlet:jstl:1.1.2",
            "taglibs:standard:1.1.2",
            "opensymphony:sitemesh:2.4.2"

    providedCompile "javax.servlet:servlet-api:2.5"
}

Again a pretty straightforward config. We use more types of dependencies. We now introduce the providedCompile. Jars that need not be included in the war should have this config for the dependency. Do mark that we have an apply plugin line at the top for creating the war. Finally have a look at the mechanism to show we have a dependency on another module of the project. We use the compile project (‘:app’) to make the war include this created jar as well.

Running with Jetty

You think the jetty plugin for maven is easy, well check this out. We have to change only one word in the web project config. Look for the first line with apply plugin. Change the word war into jetty and you are done. Now you can run jetty with the following command from the root of the project:

gradle :web-ui:jettyRun

The wrapper

People that have gradle installed on their system can easily build the project and run jetty. But some people might not have gradle installed. You can help them to make it very easy. Gradle comes with a wrapper that downloads gradle and makes sure it’s on your path etc. The only thing the user needs to do is the following in the root of the project:

gradlew build

Pay attention to the ‘w’ at the end of the gradle command. Next step is to start jetty. This is done with the same command as before with one change, the w at the end. To help your users with this, you need to do one thing. You have to add the following task to the main build.gradle. Than run gradle wrapper, checkin the generated files into your source control system. The gradlew script can be used by the people to build the project. Good stuff or not?

task wrapper(type: Wrapper) {
    gradleVersion = '0.9-rc-1'
    jarPath = 'wrapper'
}

Intellij integration

Oke, this kinda hurts to say, but intellij support is not at a level that you would like to. At least that is what I could find out. You can easily run gradle builds from intellij. That is all nice. But I am really missing the dependency management part. Would be great to have support like for maven to setup your complete project. Wouldn’t it be great to have the import from external model feature for gradle as well? For now let us all vote for this issue, it might help:

http://youtrack.jetbrains.net/issue/IDEA-57755

I hope someone from jetbrains reeds this at thinks I am important enough to start creating this plugin

Performance

The last remarks I want to make are about the performance of gradle. At the moment I have this build for maven as well as gradle and maven2 is twice as fast as gradle. I know work is being done on this. Gradle 0.9.1 will support a new feature that at least will speed up building the project of you have to do it a lot during the day. It will do something with a running gradle service that you can call each time you start a build. There are some items on the mailing list about this specific topic if you are interested.

http://gradle.markmail.org/thread/xbqna6lowvsmm4ve

Concluding

Well that was part one of the experiment. I have not touched everything by a long run. Still I found out I like the configuration of gradle a lot better than I like maven. It is a lot cleaner and let’s you focus on the things that are important. I prefer groovy for this kind of work over xml. Still gradle has some ground to cover. For starters, tool integration. We must have something that makes working with intellij a lot better. In the future I will have a better look at plugins for release management and other stuff that I think is necessary for a good project build.

I was some time a go I had a look at the sample, since than a lot of people keep coming back to it. I still get questions about it. Therefore I decided to upgrade the sample. This blog post is about the upgrade I did which are mainly upgrades in versions of the libraries and the build configuration. Still I think it is worthwhile to have a look at it.

Before I start with this blog post I need to warn you that I am not going to explain a lot of the internals. Please browse my other flex 3 blog items to find out more.

Library upgrade

The client (flex) side

For the flex building I use Mate. I think mate is a nice framework, but it is not very active. Not many improvements are created. Still it does the job. I am also creating a flex sample for the Axon Framework using Parsley. Stay tuned for a blog post that is around the corner about this sample. I upgrade the mate to release 0.8.9

Another framework I use on the flex side is the spring-actionscript project. This project changed a lot since the last time I used it. I am now using version 0.8.1. This project is now split up into a few other modules. I did have a problem with the StringUtils class. This is in as3commons:as3commons-lang. By transitive dependecy you get 0.1 of this library. I had to upgrade to version 0.2 to make it work.

The serverside

I did not upgrade a lot on the serverside. I could have upgrade to spring 3, I’ll wait till it becomes the default for the spring blazeds integration project. They still use version 2.5.6, so I’ll stick with that. I did upgrade the Spring Blazeds Integration project to the latest release: 1.0.2.RELEASE.

Building and developing

The biggest change was in the maven configuration. Flex-mojos made a lot of improvements and is now tightly integrated with Intellij. To me that is incredibly important. My development speed with flex has enormously increased.

I use flex-mojos version 3.5.0. The configuration is now very easy. For the war project you just need to add the following plugin plus configuration:

<plugin>
    <groupId>org.sonatype.flexmojos</groupId>
    <artifactId>flexmojos-maven-plugin</artifactId>
    <version>${flex-mojos.version}</version>
    <executions>
        <execution>
            <goals>
                <goal>copy-flex-resources</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Now let us have a look at the configuration of the swf file. Again it is pretty straightforward. You have to add the flex-framework as a dependency.

<dependency>
    <groupId>com.adobe.flex.framework</groupId>
    <artifactId>flex-framework</artifactId>
    <version>${flex.sdk.version}</version>
    <type>pom</type>
</dependency>

Finally we have to configure the flex-mojos compiler plugin.

<plugin>
    <groupId>org.sonatype.flexmojos</groupId>
    <artifactId>flexmojos-maven-plugin</artifactId>
    <version>${flex-mojos.version}</version>
    <extensions>true</extensions>
    <configuration>
        <debug>true</debug>
        <configurationReport>true</configurationReport>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>com.adobe.flex</groupId>
            <artifactId>compiler</artifactId>
            <version>${flex.sdk.version}</version>
            <type>pom</type>
        </dependency>
        <dependency>
            <groupId>com.adobe.flex.compiler</groupId>
            <artifactId>asdoc</artifactId>
            <version>${flex.sdk.version}</version>
            <classifier>template</classifier>
            <type>zip</type>
        </dependency>
    </dependencies>
</plugin>

The configurationReport parameter is used by intellij. This creates an xml file that intellij uses to set you compiler properties in intellij. Very nice.

Repositories

I also want to mention the additional repositories I configured. I added a repository for libraries coming from flex-mojos and another library for the spring-actionscript libraries.

<repository>
    <id>flexmojos-repository</id>
    <url>http://repository.sonatype.org/content/groups/flexgroup/</url>
</repository>
<repository>
    <id>yoolab.org-releases</id>
    <url>http://projects.yoolab.org/maven/content/repositories/releases</url>
    <releases>
        <enabled>true</enabled>
    </releases>
</repository>

The only library I still cannot find online is Mate. Therefore I added it to my google code repository. Please do the same thing if you need it for your own project. Do not use my repository because I will reach my maximum bandwidth and then I have to take it away again.

If you want to check out the state of the project while I was writing this blog, use the following tag:

http://code.google.com/p/gridshore/source/browse/#svn/tags/books-overview-1.0.0

Hope this is helpfull when exploring my sample, feel free to post remarks, improvements and questions.

This post I will talk you through a grails application I have created for a project of mine. I also take you through some of the things I learned last week. Finally I’ll show you that you can create a google app engine application using grails. There are ways to create grails applications, I’ll show you how to do it using the latest intellij 9 beta release.

Training

As mentioned in the introduction I attended the spring source groovy and grails training. The training was given by Peter Ledbrook, author of grails in action. I am not going to give a detailed description of the training. I did like the training, it gave a good overview of the possibilities of grails as well as the groovy language. And yes, I am now very interested in the options of groovy. Especially for creating web based applications with grails, groovy just shines. Not sure when I should use groovy and when normal java. Have to explore to find out. Some of the things I liked about groovy are:

• Assignment of parameters that are evaluated immediately ${age} or when used ${->age}
• Using negative indexes in arrays: [1 .. -2] strips of the first and last item from an array
• Groovy truth, explicit use of values in a comparison. null, 0, “” and [] are all false in a comparison
• Closures, still hard to determine when to use a closure and when a method. But closures are used very often in groovy.
• Out of the box test integration with things like: MockFor, Expando, and as a plugin GMock.

Of course we learned a lot more than this, check the training or the book yourself if you want more. Next up was grails. I did look at grails before at grails, but tool support was pretty limited back than, and the plugins were not really widely available. A lot has changed since than. SpringSource came out with grails support in SpringSource Tool Suite, and Intellij has grails support as well. To be honest, intellij was much more productive than STS. Actually STS was almost not useable. Since it was the first release with grails support it will most probably improve the coming releases. Intellij worked very nice out of the box (I did use the beta version of intellij 9. Some of the features I liked during the training are:

• Gorm, I must mention this Groovy/Grails Object Relational Mapping framework first. This is very important for grails and why it is so productive. I just love these dynamic finders (more later).
• Plugin architecture, the easy of installtion and usage of plugins is very nice. I like the db-util plugin for its simplicity and the help when working with internal memory databases. A killer plugin during development.
• Scaffolding, for auto responding to CRUD like operations.
• flash parameter to be used for adding something to the session for just one request. Ideal for passing messages.
• Using templates, ideal for doing ajax calls and reuse of small view elements.

Oke time to get our hands dirty, next up is a short introduction in the sample I am going to create. Than some code (which is acutally not that much)

The application to create

For a customer at JTeam, we have a large amount of servers that we need to prepare. The actual preparation is mostly done by the hosting provider. Sometime we have no idea what the status is of some servers. We started to use an excel sheet to communicate the status among our team. This is not ideal and I decided to create a small grails application for this. It’s all very basic, but useable.

Every server has a status, some comments and an external ip address. Each server is also part of a number of vlans and belongs to an environment (dev,test,accep,prod).

The code

The code is available online at github. Yes I know, it is not at google code. I got extra motivated to start using git since the training. Peter was working so flexible with his source code, I want that too. The best way to learn something is by doing it. Therefore I create a git repository at github. You can find out more at the following url. There is a very easy way to download the complete source code without using git, check the page.

http://github.com/jettro/MyServerPark

The basics

Starting a grails project is very well documented on the grails website. Except for one controller, the OverviewController, all controllers use: def scaffold = true. Which means I don’t write any code. Also not view components. I did create some domain classes that have relationships with each other. The next sections cover the different elements of the application.

The domain model

Some things to know about the domain model:

• belongsTo is used to declare a relationship of many-to-one, the next line gives an example for Comment. This gives the comment a property server.

static belongsTo = [server:Server]

• The comment class also gives meta data about the mapping and the type used for the database as well as constraints. In the example we create a field for larger amounts of text.

class Comment {
    String name
    String content

    static belongsTo = [server:Server]

    static mapping = {
        content type: "text"
    }

    static constraints = {
        name(blank:false, maxSize:50)
        content(blank:false, widget:"textarea")
    }
}

• The previous code block also shows one of the things that might be a bit strange. With widget:”textarea” you indicate the type of field to be used at the front end. Might be a bit strange in a domain model.
• A one-to-many relationship is also easy to implement, check the following line from Environment:

static hasMany = [servers:Server]

Check the code for more examples of relationships.

Scaffolding controllers and views

Grails makes use of scaffolding, this can be static and dynamic. In the static case, code is being generated and can be altered. The dynamic case is evaluated runtime. In this project I tried to use dynamic scaffolding as much as possible. Usability might not always be what you want. In that case you should use static scaffolding or create something yourself. I managed to do well with the scaffolding on dynamic (except for the google app engine sample). But let us focus on the customer controller.

The overview controller

Grails makes use of convention over configuration. This is also true for controllers and views. The overview controller listens to the /overview url and points to the overview.gsp file. The following code block gives the complete OverviewController groovy class.

class OverviewController {
    def show = {
        redirect(uri:"/server/show/${params.id}")
    }

    def comments = {
        def currentServer = Server.findById(params.id.toLong())
        def allComments = Comment.withCriteria {
            server {
                eq("id",currentServer.id)
            }
        }
        render(template:"/shared/comment",model:[comments:allComments, server:currentServer])
    }

    def index = {
        def environments = Environment.list()
        [environments:environments]
    }
}

There are three methods in the controller. The show does a redirect to the show method of the server controller. The index returns list of all environments and uses the view index.gsp. The comments method is a different cup of thee. This responds to an ajax call and returns a fragment. focus on the last line for now. You can see we use the render call. This makes use of a template. Using the render call, we obtain the html and push it back to the client. The section about views will give a bit more detail. Next up are the dynamic finders

Dynamic finders

The previous code block gives a few examples of finders. In index we obtain all the environments with Environment.list(). This is the most basic finder. Another finder is in the comments method. There we obtain the server by an id. The call is findServerById and you provided an id. Another calls could be: findByFunction, findByFunctionLike “%database%”, findByFunctionIlike “%DataBase%”. You can also make combinations with And/Or and multiple parameters. Pretty cool.

The comments method also shows the Criteria API for looking up all comments for a specific server. These type of queries, limited by a related item, are not supported by the dynamic finders.

Gsp for views

Creating the views is not very hard. If you want to learn how it works, I suggest generating the scaffolding views. I want to focus on something that is just a little bit more advanced. Ajax calls. In my project I want to obtain all comments for a server using an ajax call. In the overview page we use a special tag from grails, the remoteLink. This tag does an ajax call to the server and prints the result in the div with provided id.

<g:remoteLink action=”comments” params=”[id:server.id]” update=”comments”>comments</g:remoteLink>

As you can see, we provide the server.id and we update the div with id comments.

This does not work out of the box, you must specify the prototype javascript library to be included. You can do this in the file:

views > layouts > main.gsp

Add the following line:

<g:javascript library=”prototype” />

Now everything should be fine and you can test the application. A command like grails run-app should be enough.

Documentation

If you want more information about grails, try the following references:

• http://grails.org/doc/1.1.x/
• http://groovy.codehaus.org/groovy-jdk/
• http://www.manning.com/gsmith/
• http://www.jetbrains.com/idea/nextversion/index.html
• http://www.springsource.com/training/grv001
• http://www.springsource.com/products/sts

Grails and google app engine

Grails uses plugins for all additional functionality. There is also a plugins available for google app engine. There is already good documentation available for this plugin. Therefore I keep this short. The following code block shows the commands. For more information, check the website of the plugin:

http://grails.org/plugin/app-engine

# grails create-app share-this
# grails uninstall-plugin hibernate
# grails install-plugin app-engine
choose jpa when asked
# export APPENGINE_HOME=<path to your sdk install of google app engine>
# grails app-engine run
# grails set-version 1
# grails app-engine package
# $APPENGINE_HOME/bin/appcfg.sh update ./target/war
# grails install-plugin gorm-jpa

Than I used intellij to create some domain classes and controllers. Take the following into consideration.

• Put domain classes in a package or it won’t work
• Put Controller classes in the same package
• generate views, the auto scaffolding seems not to work.

You can look at the result here : http://share-this.appspot.com/. It could well be that the app does not start the first time, a refresh might help. I’ll have a look at this in the future. There is a problem with the CPU consumption and my grails application.

Quick intro

For an eclipse user there are other steps to get things done. There is something like a plugin that might work depending on other plugins that you have installed and some eclipse magic. Sorry, I am a non believer. I prefer another IDE.

So for the non eclipse guys you need to download a zip file with all the resources you need to start working with the new sdk. I create a symbolic link to the downloaded version, that way it is easy to change for future releases.

ln -s appengine-java-sdk-1.2.0/ appengine-java-sdk

As the getting started suggest, you can now test your infrastructure with one of the provided demo’s.

./appengine-java-sdk/bin/dev_appserver.sh appengine-java-sdk/demos/guestbook/war/

Open your browser and go to the link http://localhost:8080/. You should see the following screen.

Oke, time to take the next step. The structure for an application is the same as for a web archive. There is a catch, you cannot use the war file itself, you need the exploded directory. Luckily it is very easy to do this with maven or with Intellij. Those eclipse users that are still reading this post have an easier life. They can use the wizard from the google plugin. I start off with a normal intellij java project with a web facet.

Google app engine works with servlets, so we need to create a servlet, we also need to add this servlet to the web.xml. Since the code I used is at the google tutorial, I’ll not repeat it here.

Google appengine needs an additional xml configuration file. This file is called and it looks like this:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
    <application></application>
    <version>1</version>
</appengine-web-app>

Next step in intelliJ is to make the module, you can find the exploded war in the folder out > exploded > GoogleAppEngineGuestbookWeb. Using this exploded folder you can start the appengine. We need a runner in intellij. This is not very hard to do.There are two important steps. The first step is to create a library that you add to your module. This library contains one jar file : appengine-tools-api.jar. You can find this jar in the distribution of google appengine you downloaded. If you do not know how to add a library, open the module settings (apple: command + . Create a new library and when asked say yes to add it to your module. The screen should look like the following image.

Next up is configuring a runner. Create a runner of type Application. Now use the script dev_appserver.sh, that you can find in the distribution of google appengine in the bin folder. We need to set the environment variables, the program parameters and the main class.

Main class

com.google.appengine.tools.KickStart

Program parameters


com.google.appengine.tools.development.DevAppServerMain
out/exploded/GoogleAppEngineGuestbookWeb


Check the second parameter, this is the location of the exploded war file that intellij creates for you.

Environment variables


SDK_LIB=YOUR_GOOGLE_APPENGINE_HOME/appengine-java-sdk/lib
SDK_CONFIG=YOUR_GOOGLE_APPENGINE_HOME/appengine-java-sdk/config/sdk


The screen for configuring your runner now looks like this

That is about it, now you can run the application. After running, the output in the console is:


2009-04-08 23:53:44.332 java[3557:10b] [Java CocoaComponent compatibility mode]: Enabled
2009-04-08 23:53:44.333 java[3557:10b] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000
The server is running at http://localhost:8080/


Now you can point your browser to the following url : http://localhost:8080/guestbook and Hello world should be yours.

Deployment

Before you can upload, you need to register yourself with google. If you already have an appengine account, you can request the java beta admittance. After that create a new google appengine application in your domain. That’s it, remember the name of the app you just registered because you need it in the next step.

Next up is the actual deployment, this is not a very complicated process. You can use the same directory that you use for the test server. Be sure to change the file appengine-web.xml. Add your name of the application to the application tag. If your using intellij do not forget to make the module. In my case this application name is doingjava. Now all you need during the upload is your google account name and password. Next is the command to do the actual upload


./appengine-java-sdk/bin/appcfg.sh update PATH_TO_YOUR_INTELLIJAPP/out/exploded/GoogleAppEngineGuestbookWeb


In my case you can check if it works on the following url: http://doingjava.appspot.com/guestbook.

Conclusion

This is not a conclusion on the usage of google appengine and java. For me it was an exercise to create a project in intellij and be able to use the google mock webapp runner. This seems to work nicely. The future will bring more posts about google appengine which now support java.

I do want to stress this is not a best practice, I advise to use an ant script that you can get from google at the following url. http://code.google.com/appengine/docs/java/tools/ant.html

Some important url’s

• http://www.gridshore.nl/2008/10/09/using-google-appengine/
• http://appengine.google.com/
• http://code.google.com/appengine/docs/java/gettingstarted/
• http://code.google.com/appengine/docs/java/tools/ant.html

Some of the things I like so far:

• Support for multiple runners like ant and maven2 but also some .Net things.
• Good integration with version control system, able to see change sets, who did what, etc.
• Very nice and intuitive interface.
• Historical view on all builds including results like build log and test results.
• Good integration with IntelliJ (there is also a plugin for eclipse but I have not tested it yet). With the plugin you can execute builds, watch pending changesets, initiate a remote pre-commit build. This is integrated with the source control plugin, so you can push the button run pre-commit while in the same screen as you were before. The image below gives you a nice view of the running build (if you put on your glasses).

The next image gives you an impression of the build overview screen. You can see a difference between builds initiated on the server and the ones initiated from intellij. The ones from intellij have a small pictogram of a person below the build number.

The best part, you can use Teamcity free of charge with some limitations in the amount of builders, or agents (3) and the amount of users (20). Still this gives you an excellent opportunity to do a test drive.

If you want more information or want to try it out yourself, go to the following website: http://www.jetbrains.com/teamcity/

Powered by Qumana