ThoughtWorks, announced the general release of Cruise, a continuous integration and release management system. ThoughtWorks, are also creators of the open source CI Server CruiseControl. Cruise introduces the powerful concept of pipelines, which makes it simple to manage and test changes in an application from check-in through deployment.

ThoughtWorks is offering a free 30-day trial of Cruise (on Windows, Mac OS X and Linux), following which it will remain free to use for teams requiring two or fewer software agents. In addition, Cruise will be available at reduced or no cost for most open source projects, academic institutions and non-profit organizations.

For more details visit:

1. Cruise

An automated build process with Ant is one of the most crucial things required in any CI process. Ant is the build tool of choice for many Enterprise Java projects. This is an XML file, usually called build.xml, which describes a project’s dependencies. At the beginning of any project, this build file will be somewhere around 70-80 lines, which would include targets for compiling source and tests, running these tests, creating the libraries, and so on… But, as the project grows, this file grows as well and becomes as huge as several thousand lines; which is complicated and hard to maintain.

At this point, you might decide to refactor the build file, but before you being to do so, it would really help if you had a bigger picture of this several thousand lines of XML file, right? As the proverb goes “A picture is worth a thousand words,” I will show you how this one picture we are just going to create shows several lines of XML files.

1. Download the libraries.
I have tested diagrams from both Grand as well Vizant. I didn’t see any significant difference in either one of them. So, based on your preference and the license, download the libraries from here:

• Grand
• Vizant
• Graphviz The dot file needs to be post-processed with Graphviz to produce the actual graph.

2. Create an Ant Target.
I have two listings show below here; one for Grand and one for Vizant. If you have used custom ant tasks, the listing shown below is self explanatory. Before using either Grand or Vizant, define a task. Next, give the name of the build file, its location, and the output. To view the graph you need to transform the dot file into something else using the dot command. In our case, we are generating a PDF file, but you can generate any other format as well; like JPG, PNG and so on.

Listing 1 for Grand:

<target name="grandAntDiagram">
    <typedef resource="net/ggtools/grand/antlib.xml" classpath="${basedir}/lib/grand-1.8.jar" />
        <grand output="build.dot" buildfile="${basedir}/build.xml" />
		<exec executable="dot">
		  <arg line="-Tpdf -Gsize=11.69,8.27 -Grotate=90 -o build.pdf ${basedir}/build.dot" />
		</exec>
</target>

Listing 2 for Vizant:

<taskdef name="vizant" classname="net.sourceforge.vizant.Vizant" classpath="${basedir}/lib//vizant-0.1.2.jar" />
<target name="vizantAntDiagram">
		<vizant antfile="${basedir}/build.xml" outfile="vizant-build.dot">
			<attrstmt type="graph">
				<attr name="ranksep" value="1.2" />
				<attr name="nodesep" value="0.5" />
			</attrstmt>
		</vizant>
		<exec executable="dot">
			<arg line="-Tjpg vizant-build.dot -o build.jpg" />
		</exec>
</target>

3. Run the Target.
You can run the targets from the command lie, from the IDE of your choice or from your CI server by just calling the above targets.

mobile-166-217-041-119:webservices-samples meerasubbarao$ ls
build.dot		dist			run.bat
build.pdf		instrumented		src
build.properties	lib			test
build.xml		passfile		vizant-build.dot
classes			qalab.xml
cobertura.ser		reports
mobile-166-217-041-119:webservices-samples meerasubbarao$ ant grandAntDiagram
Buildfile: build.xml

grandAntDiagram:
    [grand] Loading project /Users/meerasubbarao/Development/webservices-samples/build.xml
    [grand] Setting up filter chain
    [grand] Writing output to /Users/meerasubbarao/Development/webservices-samples/build.dot
    [grand] Outputing to /Users/meerasubbarao/Development/webservices-samples/build.dot

BUILD SUCCESSFUL
Total time: 0 seconds
mobile-166-217-041-119:webservices-samples meerasubbarao$

Here are some sample diagrams for the build files I had.

1. A simple one, this was the build file I used for my article I wrote for Javalobby.

2. And, this one which was generated by an IDE for another article I was working on. Does your build file look like this? If it does, than it is time to refactor the build files heavily.

P.S: The listings shown above in itself are sufficient for you to get the diagrams working in your build files, the one thing you will need to change is the location of the libraries. Also, don’t forget to download and install Graphviz, if not you will get an exception like this:

BUILD FAILED
/Users/meerasubbarao/Development/webservices-samples/build.xml:107:
      Execute failed: java.io.IOException: dot: not found
Total time: 269 milliseconds

Is this even possible? Yes, trust me, if I can do it, so can you. You may ask, from Groovy and Grails in one day, how did I shift gears to web services. It all started while I was reading and working the samples from chapter 9 Web Services of “Beginning Groovy and Grails from Novice to Professional“. With the help of the sample provided in the book, I was able to get a RESTful web services for the Grails application.

However, I wanted to learn more about the same and write a simple RESTful web service in Java. It is traditional to start with a Hello World example while learning any new technology, right? So, lets not break the tradition and continue with the Hello World example I tried.

To follow this tutorial, you need the following software and resources.

1. NetBeans IDE 6.x, I had the latest 6.5 M1 version downloaded.
2. JDK version 5 or 6
3. GlassFish V2 Application Server
4. Last but not the least, knowledge about REST. Here are some links to get you started:

• RESTful Web Services
• Implementing RESTful Web Services in Java
• JSR 311: JAX-RS: The JavaTM API for RESTful Web Services

Creating a New Project:
1. Choose File -> New Project. Select Web within the Categories and select Web Application under Projects and click Next.

2. In the next screen, enter the project name as “HelloWorldRestWS”. Leave the rest as default as shown below:
.

3. In the screen shown below, select GlassFish V2 as the server, Java EE 5 as the Java Version, and HelloWorld as the context path and click Finish.

Creating a Web Resource:
Now, that we have our web application, lets create a simple Java Class for our web resource. To do this:

1. Right click on the project node, and select New - RESTful Web Services from Patterns… This will bring up a wizard as shown below, select the Singleton Pattern and click Next.

2. Next, specify all the details required for the Resource class and click Finish. Don’t forget to change the MIME Type from application/xml to text/plain.

3. At this point, take a look at the source code generated by the IDE, which looks like:

/*
 *  HelloWorldResource
 *
 * Created on July 23, 2008, 10:13 AM
 *
 * To change this template, choose Tools | Template Manager
 * and open the template in the editor.
 */

package com.stelligent.ws;

import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;
import javax.ws.rs.Path;
import javax.ws.rs.GET;
import javax.ws.rs.PUT;
import javax.ws.rs.ProduceMime;
import javax.ws.rs.ConsumeMime;

/**
 * REST Web Service
 *
 * @author meerasubbarao
 */

@Path("helloWorld")
public class HelloWorldResource {
    @Context
    private UriInfo context;

    /** Creates a new instance of HelloWorldResource */
    public HelloWorldResource() {
    }

    /**
     * Retrieves representation of an instance of com.stelligent.ws.HelloWorldResource
     * @return an instance of java.lang.String
     */
    @GET
    @ProduceMime("text/plain")
    public String getText() {
        //TODO return proper representation object
        throw new UnsupportedOperationException();
    }

    /**
     * PUT method for updating or creating an instance of HelloWorldResource
     * @param content representation for the resource
     * @return an HTTP response with content of the updated or created resource.
     */
    @PUT
    @ConsumeMime("text/plain")
    public void putText(String content) {
    }
}

Testing the RESTful Web Services:
1. Let’s try this application and see first hand if it works. Right click on the project node and select “Test RESTful Web Services“. The GlassFish V2 application server starts, our web application is deployed, and at this point you should see a link for the web service as shown below, choose the GET method to test.

2. Oops, something went wrong, Internal Server Error?

3. No problem, we can fix this. Let’s fix our getText method which is the culprit for our error.
It was:

    /**
     * Retrieves representation of an instance of com.stelligent.ws.HelloWorldResource
     * @return an instance of java.lang.String
     */
    @GET
    @ProduceMime("text/plain")
    public String getText() {
        //TODO return proper representation object
        throw new UnsupportedOperationException();
    }

 

Let’s change it to:

    /**
     * Retrieves representation of an instance of com.stelligent.ws.HelloWorldResource
     * @return an instance of java.lang.String
     */
    @GET
    @ProduceMime("text/plain")
    public String sayHello(){
        //TODO return proper representation object
        return "Hello World from REST web services generated in 60 seconds";
    }

 

4. At this point, run the application again and you should get a valid response back.

That’s it. We were able to successfully create, deploy and test RESTful web services. Give it a try, it is just a matter of 60 seconds.

I’ve used Rails now for close to three years, and I’ve been teaching myself Grails for a new project.

Initial Thoughts
Grails is close enough to Rails to make getting started easier, and far enough away to be confusing in some ways. I had to learn Ruby while I was learning Rails, so there was a ‘double challenge’ there. I’ve been using Groovy for 6 months now, so with Grails the learning curve is much more shallow.

Cool things about Grails
I like the idea of having the domain objects define the database, instead of the other way around. One of the things that annoys me about Rails is having to go fire up MySQL every time I can’t remember what fields are on a class.

I like the built-in java integration, and IntelliJ’s support for Grails seems very solid.

Having HSQL built-in is very nice! That’s a big win.

Frustrating things about Grails
I have run into several bugs that leave me scratching my head - strange exceptions that keep the database from being automagically updated, and I find the different ways to handle error messages confusing.

In Grails’ defense, I don’t have a book to draw from - I’m looking at online examples and the InfoQ PDF. And some of this will go away with a little more practice.

And, all things considered, those are fairly minor complaints. Mostly what I’m struggling with right now is my own ambitious vision for the project.

Stelligent friend and author of O’Reilly’s Java Power Tools, John Ferguson Smart recently blogged about easyb, in which he states that easyb has a

very readable Domain Specific Language (DSL), that you use to write very readable (pretty much self-documenting, in fact) test cases. Rather than reasoning in terms of asserts, or even assertThats, you describe your test case in terms of simple structured user stories. Instead of assert statements, you have expressions such as shouldEqual, shouldBeLessThan and shouldHave (for collections), which have the same natural feel as Hamcrest expressions, and are just as readable.

He also provides an illustrative example of withdrawing bank funds, in which he leverages both the DSL’s should syntax as well as the ensureThrows clause (which is quite helpful in testing negative paths) in an attempt to validate proper behavior.

What’s more, if you are fortunate enough to live near or in New Zealand, you’ll want to attend the Java Emerging Technologies Conference 2008, which is going to be held this September in Auckland. The conference is free and best of all, there’s going to be a talk on easyb.

After having read the book Beginning Groovy and Grails: From Novice to Professional, I was wondering if it was ever going to be as simple as a few clicks in any IDE for Grails development. Just yesterday, I read an article by Geertjan Wielenga(who is also my colleague at Javalobby/DZone) about how to get started with Grails in NetBeans IDE 6.5 in 5 simple steps. I had worked with NetBeans quite a lot for EJB3 development but I had never used it for either Groovy or Grails; the choice earlier was always Eclipse IDE.

I first followed the Book Demo and later moved to a more real life example. This was a litmus test which I thought NetBeans had to pass for developers to continue using the same for Groovy/Grails development. The example in the book has a few relationships; which is what we would generally have in any enterprise application.

I was able to create all the domain classes, controllers, manage relationships without ever leaving the IDE. Creating a Domain class or even a Controller, is as simple as right clicking on the appropriate nodes and providing meaningful names. The IDE creates the skeleton classes; we need to provide the meat within and here is what the Todo Domain class looks like:

class Todo {
    String name
    String note
    Date createdDate
    Date dueDate
    Date completedDate
    String priority
    String status

    User owner
    Category category

    static belongsTo = [User, Category]

    static constraints = {

        name(blank:false)
        createdDate()
        priority()
        status()
        note(maxSize:1000, nullable:true)
        completedDate(nullable:true)
        dueDate(nullable:true)

    }

    String toString() {
        name
    }

}

Right-click the application in the IDE and choose “Run”. The application is deployed to Jetty, and then you’ll see your application as shown below:

If you are a Groovy or a Grails fan, download the latest version of NetBeans and give it a try. You can develop, test and run your Grails application without ever opening a command window. The Groovy editor has basic coloring, formatting and bracket completion. The GSP editor has coloring, highlighting of GSP tags, expressions and scriptlets. You can mix and match Java and Groovy as well.

P.S: Groovy and Grails home needs to be set from within the IDE NetBeans/Preferences as shown below:

Resources:

• Highlights of Beginning Groovy and Grails from Novice to Professional
  
• Groovy cross-platform installer
• Grails Quick Start in NetBeans IDE

Just yesterday, I posted a detailed review of the book “Persistence in the Enterprise: A Guide to Persistence Technologies” on Java Zone and a few other relevant zones. I wanted to share with you two very unique aspects of this book that are sure to help every developer.

1. If you are a CTO, an architect, a developer or even a tester, this book will help you ask the right kind of questions before you choose a persistence framework; comparing JDBC™, Apache iBATIS, Hibernate Core, Apache OpenJPA, and pureQuery. With this book, you’ll learn how to define requirements for your persistence tier, choose the right solution for your organization, and build and test enterprise systems that help maximize both performance and value.

2. The next thing that makes this book so unique is the tests written for each of these frameworks. The authors have free source code download, and you can learn how to write tests using JUnit and DBUnit for all these persistence frameworks. I have seen developers at a loss when writing unit tests for their persistence tier. This book gives you complete step by step instructions on how to run these samples and tests; via a common example application.

So, lets get started writing tests and see that we get at least 80% code coverage(strive for 100%) for our persistence tier.

P.S: For those of you who are Safari Books Online subscribers, the book is available there in:
http://safari.informit.com/9780131587564. I read the hard copy the hard way.

Downloading Groovy 1.5.6 is just one click with the new cross-platform installer which was made available by IzPack. Download the installer directly from here and just double click and follow the steps by clicking the Next button and you are all set to use Groovy. Below is a screen shot of the installer running on Mac. I did test it on my windows desktop as well, works like a charm. Give it a try.

Authors Christopher Judd, Joseph Faisal Nusairat and Jim Shingler are getting beginners started with Groovy and Grails, taking a practical approach to teaching how to develop productive Grails web applications. Covering all the basics and some advanced topics of the Groovy language that is necessary for Grails application development, readers are guided through the process of writing a fully featured web application.

Everyone wanting to discover and use Groovy and Grails will gain the insight and skills needed to start creating their own applications.

The main highlights of this book are:
# Full coverage of basic Grails features of scaffolding, domains, controllers, services, and Groovy Server pages
# Tackles common web application challenges such as security, Ajax, web services, reporting, batch processing, and deployment
# Includes a Swing desktop client built in Groovy that integrates with the application using the exposed web services

Who should read this book
This book is for Java developers and organizations looking to become more productive by taking advantage of dynamic languages and solid agile web frameworks while lever-aging current investments in infrastructure, code, and education in the Java platform. It is for those who want to build internal applications and mission-critical, Internet-facing applications.
This book does not assume the reader has a strong Java or Groovy background, so those familiar with other dynamic languages like Perl, Ruby, Python, or PHP will find this a great source for investigating the Groovy and Grails alternative.

How This Book Is Oragnized
In this book, you’ll explore how to build command-line, Swing, and web applications using the Groovy language and the Grails web framework. The step-by-step approach will take you from a simple to a complex and fully featured Web 2.0 application. Chapters 1–3 provide a basic Groovy language primer, while Chapters 4–12 explain how to build and deploy web applications using Grails. The final chapter explains how to use Groovy and Swing to build a desktop client that interacts with the Grails web application.

You can find more information, table of contents and sample chapter online here: http://www.apress.com/book/view/1430210451

Downloading the Code
The code for the examples in this book is available to readers in the Source Code/Download section of the Apress web site at http://www.apress.com or on the book’s website at http://www.beginninggroovyandgrails.com.

Consultant Eric Minick says that CI should be focused on testing, not on builds.

He makes the following interesting points:

• automated tests verify successful integration, not the compilation/build process
• running a build multiple times with different test “suites” is complicated and error prone
• performing many different kinds of builds in an enterprise environment is wasteful and much of the testing is outside of source control

His recommendation is that a given software “build” (a set of packaged software bits that represent the output of the compile/generation process) should be passed through multiple testing stages over time. Personally, I visualize this like a car going through a car wash - we don’t build a new car for each brush and spray hose - we use the same car over time.

My take: I think, conceptually, that there’s a lot of merit here - because if you have an active project with a lot of commits, and you’re firing off all sorts of different builds with different test profiles, you are dealing with a constantly changing code-base as you run different types of tests. In other words - the code that you run the “database” integration tests on might be subtly different from the code you run the “web services” integration tests on.

And that’s a fair point - there are situations where you end up with a bug that “slides between” two types of builds. Eric’s solution certainly addresses that issue, in a reasonably elegant way.

However:
A) those issues don’t happen that often, in my experience (if they happen all the time to you, then definitely consider Eric’s idea)
B) Most sites I know of have at least one “Mother of all Test Suites” to cover and catch bugs that slip past the “lesser” test suites.
c) The amount of “waste” involved in fairly meaningless

I applaud UrbanCode’s innovative thinking. If this is something that speaks to you, by all means, give it a try. But don’t trash your existing build model just yet.