Just Do It!

After announcing my plans to compare Ant, Maven and Gradle implementations in my previous post Ant, Maven, Gradle…or something else… almost 2 months ago, I have finally found some time to begin my little experiment.

The initial implementation involves the use of Ant with Ivy, to build and test a simple Java class. Dependencies including Ivy itself, JUnit 4.8.2 and OpenPojo should be obtained as part of the build itself. Anyone wishing to use the build should only require a working Java environment and Ant installed. It appeared to be simple enough in principle. It turns out to be a little more complicated in practice.

Challenges encountered with this implementation thus far:

• Bootstrapping of Apache Ivy (this was expected)
• JUnit 4.8.2 has not been released into any Maven repositories
• OpenPojo doesn’t exist in any Maven repositories

The repository issues will affect all of the implementations. This lead me to consider adding a local repository manager (to which I could install the required artifacts) to the experiment.

With Ant/Ivy I can bootstrap the appropriate artifacts and install them locally. I believe adding a local repository manager such as Artifactory, Archiva or Nexus would provide a better solution – but at the expense of adding  a requirement that the user have a repository manager installed (with the appropriate artifacts) for the build to run successfully. Thus for the Ant/Ivy implementation I don’t plan to use a repository manager.

So that leaves me with the 3 challenges to meet. I shall deal with each of these in a separate blog entry, as and when I have completed a reasonable solution. I shall also post the relevant code to GitHub for those interested in testing it and providing feedback.

Do you have any comments about the implementation? Should I be using a repository manager? What is the best way to bootstrap the required artifacts? Any suggestions/ideas? If so please add them in a comment below.

Arrested for not using a build tool!!

Do you use a build framework? Which build framework do you use? Is your build framework open-source, commercial or even custom? Ant, Maven and Gradle are three open-source build frameworks that I plan to use in a build experiment.

The experiment is intended to be the first of many set around the build process. Future planned experiments include the integration of these frameworks with repository managers, continuous build integration, static code analysis/error detection and reporting capabilities to determine technical debt.

The Experiement

I intend to create a simple build using each of these frameworks. Each build is required to:

• Use JUnit 4.8.2
• The latest version of OpenPojo (used in the small application to test)
• The build framework is the only requirement to perform the build in a Java environment
• Dependencies should be retrieved or bootstrapped when required

Once each of the builds has been created I intend to compare them. Comparisons should provide useful feedback for the builds in this context. Current comparisons I am considering involve comparison of:

• Implementation time and complexity
• Dependency management flexibility
• The ability to tailor the build configuration

The Frameworks

Ant [Apache Ant Website]

I have been using Ant as part of my Java development for as long as I can remember. Having hand crafted numerous build files using Ant’s verbose XML syntax and extended Ant via custom tasks, it is my staple build framework of choice. I enjoy the flexibility it provides and the ability it offers to tailor builds to meet specific requirements.

For this experiment I am conscious that Ant will require the bootstrapping of Apache Ivy to enable dependency management. This means there will be added complexity from the start for the Ant build. This added complexity though is tempered by the flexibility Ant will offer me to perform the other tasks.

Maven [Maven Website]

I have experience using Maven but have not yet been convinced it is worthy of replacing Ant in my build processes. Maven 1.0 and 2.0 had failed to convince me that I should ditch Ant just yet, maybe Maven 3.0 will change that! When working with Maven I have encountered the need to revert back to Ant for certain unorthodox build steps. Maven does appear to have some flexibility issues, and I have been privy to several discussions around these issues. I do believe the tool does have benefits, such as its dependency management, and have included it in this experiment as a chance for Maven to demonstrate that it has what it takes to be considered as my build tool of choice.

Most of my Maven experience has involved the maintenance of and the addition of functionality to existing pom files rather than building the pom from scratch. The Maven build should prove simple to implement unless the specific JUnit version requirement causes the test phase of the build issues. I am hoping Maven can pleasantly surprise me with its simplicity to meet the experiment requirements.

Gradle [Gradle Website]

Gradle is the new kid on the build framework block. Having recently built a Grails application and delved into the world of Groovy I am eager to see if this framework can compete with the more established Ant and Maven. Will it prove to have the flexibility of Ant enhanced by a Groovy script implementation along with dependency management comparable to that of Maven?

I have not even download Gradle yet! Some time ago I intended to look at GAnt as an Ant alternative. GAnt is not a build framework. It enables Ant builds to be built using the Groovy syntax rather than using the Ant verbose XML equivalent. Gradle uses Apache Ivy for dependency management (as the Ant build will do). Having experienced the increased efficiency Groovy can provide utilizing the power of Groovy scripts in the build process is very appealing to me.

The Expectations

I believe Ant whilst offering the most flexibility will prove to be the most complex of the builds largely due to the need to bootstrap dependency management and its verbose XML syntax.

Maven has excellent dependency management built in but the requirement to use a specific version of JUnit may cause issues with the built in test phase?

If Gradle does provide the flexibility of Ant along with dependency management comparable to that of Maven combined with a Groovy scripting nature it could prove to be my build tool of the future.

I am interested in hearing about alternative build frameworks worthy of investigation, as well as build experiences relevant to this experiment. I would also be interested in ideas to extend this experiment that would provide more realistic project comparisons – really pushing the framework limits etc.

I will be storing the build scripts on GitHub and will post the link once the first implementation has been committed.

Replacing these System.out.println() statements with log statements is the first improvement on this technique. Using SLF4J (Simple Logging Facade for Java) provides some neat improvements using parameterized messages. Combining SLF4J with JUnit 4 rule implementations can provide more efficient test class logging techniques.

Some examples will help to illustrate how SLF4J and JUnit 4 rule implementation offers improved test logging techniques. As mentioned the inital solution by developers is to use System.out.println() statements. The simple example code below shows this method.

import org.junit.Test;

public class LoggingTest {

  @Test
  public void testA() {
    System.out.println("testA being run...");
  }

  @Test
  public void testB() {
    System.out.println("testB being run...");
  }
}

The obvious improvement here is to use logging statements rather than the System.out.println() statements. Using SLF4J enables us to do this simply whilst allowing the end user to plug in their desired logging framework at deployment time. Replacing the System.out.println() statements with SLF4J log statements directly results in the following code.

import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class LoggingTest {

  final Logger logger =
    LoggerFactory.getLogger(LoggingTest.class);

  @Test
  public void testA() {
    logger.info("testA being run...");
  }

  @Test
  public void testB() {
    logger.info("testB being run...");
  }
}

Looking at the code it feels that the hard coded method name in the log statements would be better obtained using the @Rule TestName JUnit 4 class. This Rule makes the test name available inside method blocks. Replacing the hard coded string value with the TestName rule implementation results in the following updated code.

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TestName;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class LoggingTest {

  @Rule public TestName name = new TestName();

  final Logger logger =
    LoggerFactory.getLogger(LoggingTest.class);

  @Test
  public void testA() {
    logger.info(name.getMethodName() + " being run...");
  }

  @Test
  public void testB() {
    logger.info(name.getMethodName() + " being run...");
  }
}

SLF4J offers an improved method to the log statement in the example above which provides faster logging. Use of parameterized messages enable SLF4J to evaluate whether or not to log the message at all. The message parameters will only be resolved if the message will be logged. According to the SLF4J manual this can provide an improvement of a factor of at least 30, in case of a disabled logging statement.

Updating the code to use SLF4J parameterized messages results in the following code.

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TestName;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class LoggingTest {

  @Rule public TestName name = new TestName();

  final Logger logger =
    LoggerFactory.getLogger(LoggingTest.class);

  @Test
  public void testA() {
    logger.info("{} being run...", name.getMethodName());
  }

  @Test
  public void testB() {
    logger.info("{} being run...", name.getMethodName());  }
  }
}

Quite clearly the logging statements in this code don’t conform to the DRY principle.

Another JUnit 4 Rule implementation enables us to correct this issue. Using the TestWatchman we are able to create an implementation that overrides the starting(FrameworkMethod method) to provide the same functionality whilst maintaining the DRY principle. The TestWatchman Rule also enables developers to override methods invoked when the test finishes, fails or succeeds.

Using the TestWatchman Rule results in the following code.

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.junit.rules.TestWatchman;
import org.junit.runners.model.FrameworkMethod;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class LoggingTest {

  @Rule public MethodRule watchman = new TestWatchman() {
    public void starting(FrameworkMethod method) {
      logger.info("{} being run...", method.getName());
    }
  };

  final Logger logger =
    LoggerFactory.getLogger(LoggingTest.class);

  @Test
  public void testA() {

  }

  @Test
  public void testB() {

  }
}

And there you have it. A nice test code logging technique using JUnit 4 rules taking advantage of SLF4J parameterized messages.

I would be interested to hear from anyone using this or similar techniques based on JUnit 4 rules and SLF4J.

GalleryView Plugin Example

Prior to Christmas I came across another list of great jQuery Plugins. This list (11 Amazing JQuery Gallery) contained the GalleryView Plugin which was visually impressive but looked quite simple to implement. The plugin website states that it:

aims to provide jQuery users with a flexible, attractive content gallery that is both easy to implement and a snap to customize.

The Plugin website has several demos. These demos show the flexibility of the plugin. As well as the default implementation there are demos that show how to use the Plugin as a LightBox style replacement and even how to create an HTML content panel using the Plugin. It is well worth checking out all of the demos to get a feel for just what the Plugin is capable of.

Worth a special mention is the implementation on the sites evolution page. On this page the GalleryView Plugin is used to show the evolution of the site in pictures during 8 days of development. A great example of ingenious ways to use this flexible Plugin.

I was interested in a simple and visually impressive gallery viewer, but this Plugin delivers more than that. I could see uses for this Plugin when creating dynamic content viewers, work portfolios and much, much more. So time for some implementation…

I begun my implementation by following the usage section on the Plugin sites homepage…and ended up with a complete mess! I had failed to notice the authors note at the top of the page:

this entire page is now out of date, as it talks about GalleryView 1.1. For the lastest version, 2.0, please check out http://plugins.jquery.com/project/galleryview.

Being away from home (with no internet access) for the break I had downloaded copies of the relevant pages. At this time I considered putting my attempts to get the example up and running on hold. This seemed to be a bit of a cop out to me. So I delved into the 2.0 source code in an attempt to determine the markup and styles required. I found the source code quite easy to read and understand, and soon had an almost fully functioning example. I was still having an issue with the filmstrip – so decided to complete the example when I returned from my break.

Implementation

My GalleryView Example

View the example

In order to use the Plugin you need to use the jQuery javascript library, the GalleryView Plugin, the jQuery Timer Plugin and the jQuery Easing Plugin. The dependencies are included in the GalleryView Plugin download. Include these libraries in any pages you wish to use the Plugin.

Only a very simple piece of JavaScript is required to get the Plugin up and running:

<script type="text/javascript">
  $(document).ready(function(){
    $('#photos').galleryView({
      panel_width: 800,
      panel_height: 300,
      frame_width: 75,
      frame_height: 75
    });
  });
</script>

This simple bit of script calls the Plugins galleryView method with a minimum configuration set. Our panel and filmstrip frames will be set to the pixel sizes specified here. There are many more configurations available. If you want to know what configuration options there are check out the 2.0 release notes as well as those listed on the Plugin site.

There are links from the out of date Plugin website (in the comments) to some example of 2.0 code provided by a third party. These links were not working when I tried them. I was able to track down the right pages on the linked to site though. So with a bit of help from this example on appleton.me I was able to create a fully functioning example with the following very clear and concise bit of HTML:

<ul id="photos">
 <li>
   <span>Auckland City from North Head, Devonport</span>
   <img src="../../img/gallery/auckland.jpg" />
 </li>
 <li>
   <span>Lion Rock, Piha</span>
   <img src="../../img/gallery/lion_rock.jpg" />
 </li>
 <li>
   <span>Rangitoto</span>
   <img src="../../img/gallery/rangitoto.jpg" />
 </li>
 <li>
   <span>Fern</span>
   <img src="../../img/gallery/fern.jpg" />
 </li>
 <li>
   <span>River</span>
   <img src="../../img/gallery/river.jpg" />
 </li>
 <li>
   <span>Waves</span>
   <img src="../../img/gallery/waves.jpg" />
 </li>
 <li>
   <span>Piha: Looking towards 'The Gap'</span>
   <img src="../../img/gallery/towards_the_gap.jpg" />
 </li>
</ul>

The example page seems to be the most active page for the Plugin at this time. It even seems the developer has put the Plugin out to seed at this time. Jack Wanders stated on his Twitter account on 6th July 2009:

My apologies, but GalleryView and spaceforaname.com are officially dead in the water until further notice; occupied w/ other matters atm

Hopefully either he or someone else will pick up the Plugin as it certainly does have some great uses. If you are aware of the latest news related to the Plugin please let me know.

One thing I would particularly like to see is the IE7 Panel Overlay fade in/out issue fixed sometime soon (maybe I should do that myself after delving in to the source code) as I feel this could be a ‘BLOCKER’ for production uses. Setting the panels to not fade and switch instantly is a workaround in most situations.

Lists of other jQuery Gallery Plugins etc I have come across:

• Top 14 jQuery Photo Slideshow / Gallery Plugins
• 15 Amazing jQuery Image Gallery/Slideshow Plugins and Tutorials
• 25  jQuery Slider/Image Gallery Tutorials and Plugins
• 15  jQuery Plugins For A Better Photo Gallery And Slideshow

If the GalleryView Plugin doesn’t meet your needs or is not your cup of tea, maybe you will find something in these lists that does.

Purchase JQuery In Action 2nd Edition MEAP Edition

WordPress has recently been updated to version 2.9. This new version includes a super easy way to include embeddable media in posts via Embeds. Thought I would give this new feature a work out by embedding one of my favourite television moments of all time…from classic BBC Comedy Only Fools and Horses – Del Boy prepares to make a move on some hot chicks whilst out on the town with Trigger…

Am sure I will find more uses for this great new feature. To find out what other new features are included check out the release blog post.

JUnit has also recently been updated to version 4.8.1. This version  follows close on the heals of the 4.8 release which introduced Categories to JUnit. Check out the Category changes and implementations  in the release notes.  The Categories implementation is marked by the authors as preliminary, not sure what is meant by that – as surely it would be difficult to remove it once people start using it! 4.8.1 fixes bugs in the Categories documentation and implementation reported by early implementors. I shall be taking a look at the implementation ASAP.

Lately I have been working on an interesting project at work that implemented a Grails/Groovy server and a .NET Extraction client. Most of my time was spent on the .NET client extractor which has been an interesting, if somewhat frustrating experience.

Today I got moved to a new project which looks like it could be really interesting. It involves the use of Tohu, an open source JBoss Drools based library for use in dynamic questionnaire based implementations. Solnet Solutions are the main developers of this open source implementation. I have been interested in making commercial use of Drools for a long time, and this project will give me the opportunity to get some real experience in this area. Tohu also currently only supports a JQuery UI. With JQuery being another of the technologies I have dabbled in but never really used in earnest as yet.

I have set myself a few goals for the coming months. Among them is blogging about the JUnit Categories updates and completing my review of the 3.7 changes. I will outline more of my plans and goals for the year in upcoming blog posts.

Off for a chat....

I have uploaded the slides from my JUnit Goodness presentation to Slideshare.

I outlined the presentation in my last blog entry. The slideshow can be reached by clicking on the link below:

JUnit Goodness on Slideshare

Would appreciate any feedback and comments that viewers wish to provide. I shall upload the example code sometime next week and am considering turning the slideshow into a videocast.

Testing: The Dark Side?

It feels like an eternity since I last sat down to write some blog content!!

The last month or so I have been busy updating a ‘JUnit Goodness’ presentation for use at the Auckland JUG October 2009 meeting. The presentation focuses on 3 aspects of JUnit 4 that I feel may have slipped under the radar of developers introduced to JUnit at version 3. Parameterized tests, matcher assertions and the @Ignore annotation were the 3 aspects I chose to include in this presententation.

The parameterzied test section of the presentation attempts to outline a process that may lead a developer to utilize a parameterized test. The realization that duplicated code can be replaced by a looping test leads the devloper naturally in  the direction of a parameterized test. The presentation aims to offer answers regarding why and when to use parameterized tests and how to write them. Also included in the presentation is a named parameterized test extension and an XML data driven parametrized test extension that I had recently implemented.

Matcher assertions arrived in JUnit 4 via JMock. The presentation aims to demonstrate the advantages of using matcher assertions compared to the legacy JUnit assertions. Matcher assertion readability, clarity of failure messages, combination matcher usage and the benefits of list matchers are all presented. The creation of custom matchers is also present, albeit through a crude over simplified example.  To finish the presentation there is a look at the somewhat under utilized IMHO @Ignore annotation and how it can fit in to improved testing practices.

Auckand JUG Duke

The majority of those present at the presentation were still using JUnit even though TestNG has built up quite a following and viewed by some as the next generation test tool. TestNG has useful features such as parallel testing and data driven testing using the @DataProvider annotation that JUnit does not. Why has there not been a shift to this next generation test tool? Is it down to the lazy developer syndrome? The we know this tool, why waste time learning a similar tool attitude? Some of the attendees were aware of TestNG and the benefits it offers when writing certain types of tests – yet still used JUnit for there project test needs.

Many of those present were unaware of the benefits that the 3 aspects presented provided. There was the odd attendee who had dabbled with one or two of the aspects, but none had really dug too deep. Hopefully I provided everyone with something to think about whenever they are writing JUnit tests in the future.

I had expected the parameterized tests section, particularly the named and XML data-driven extensions would be the ‘WOW’ factor of this particular presentation. This was not the case though. The actual ‘WOW’ factor turned out to be the clarity of the matcher assertion failure messages compared to their legacy equivalents. Flicking between the two versions on the big projector screen seemed to exacerbate the clarity.

I would be surprised to see any of the developers present not using matcher assertions from now on based on what they saw. The @Ignore annotation usage did lead into a group discussion regarding how useful it was, how it could be abused and the best ways to use it.

I plan to upload a slightly updated version of the presentation to SlideShare later this week.

Purchase JUnit In Action 2nd Edition MEAP Edition

Mommy's Little Test Developer

Continuing with my look at the new core rules in JUnit 4.7 this blog entry will look at the Verifier core rule. This rule is the base class for rules like the ErrorCollector rule which I looked at in a previous post. Using the Verifier core rule it is possible to turn tests which would otherwise pass into failing tests based on a verification state.

There is a single method in the Verifier class that implementors of this rule need to override. The verify method is declared with a throwable exception which should be thrown to indicate verification failure. Here is the method declaration from the Verifier class:

/**
 * Override this to add verification logic.
 * Overrides should throw an exception to indicate that verification failed.
 */
protected void verify() throws Throwable {}

When the Verifier rule is applied the following apply method is used.

public Statement apply(final Statement base, FrameworkMethod method,
  Object target) {
    return new Statement() {
      @Override
      public void evaluate() throws Throwable {
        base.evaluate();
        verify();
      }
   };
}

As can be seen once the base statement evaluation is completed the overriden verify method will be run. This enables the implementation class to fail tests which would otherwise pass.

So how could this be employed in a useful manner? Under what circumstances would it make sense to fail a passing test based on an object state ending up in an incorrect state. John Smart recently wrote an article about Testing Exceptions in JUnit 4.7 in which he implements the verify method in order to check a user is not logged in.

John states that his implementation is probably not the intended use of the Verifier rule, but I don’t think he was far from an intended use. John did provide me with a use case for the Verifier rule though. So my implementation will be used to verify that a user is still in the session once the test has run.

All John failed to implement in his example is a version of the verify method that throws an exception. Following the same pattern as the ErrorCollector rule for my UserInSessionVerifier class that extends Verifier I implemented a verify method that throws a NoUserInSessionException. Below is my UserInSessionVerifier class code:

import javax.servlet.http.HttpSession;
import org.junit.rules.Verifier;

public class UserInSessionVerifier extends Verifier {

  HttpSession session;

  public UserInSessionVerifier(HttpSession session) {
    this.session = session;
  }

  @Override
  protected void verify() throws Throwable {
    NoUserInSessionException.assertNotEmpty(session);
  }
}

As can be seen this is a fairly simple class which extends the Verifier rule class and overrides the verify method. This overriden method throws a NoUserInSessionException if the session user state verification fails, that happens if the session does not contain a user. The session property is initialized in the constructor, which is then passed by parameter to the assertNotEmpty static method of the NoUserInSessionException class. Lets take a look at that class now:

import javax.servlet.http.HttpSession

public class NoUserInSessionException extends Exception {

  private static final long serialVersionUID = 1L;
  private final HttpSession session;

  public NoUserInSessionException(HttpSession session) {
    this.session = session;
  }

  public HttpSession getSession() {
    return this.session;
  }

  public static void assertNotEmpty(HttpSession session) throws Throwable {
    if (session.getAttribute("userName") == null
          || session.getAttribute("userName").equals("")) {
      throw new NoUserInSessionException(session);
    }
  }
}

This standard exception class extends a Throwable subclass, it also  implements the static assertNotEmpty method that contains the user state verification code. In this trivial example if the userName attribute in the session is empty or null a NoUserInSessionException is thrown – as the user state is not what we expected it to be. If the user state is as we expect – that is to say it is populated then this method will not throw an exception and the verify method in UserInSessionVerifier will not cause any tests to fail.

Having looked at our Verifier rule (UserInSessionVerifier) and its associated exception (NoUserInSessionException), lets now look at a test that uses our new UserInSessionVerifier rule.

import static org.junit.Assert.assertTrue;

import javax.servlet.http.HttpSession;

import org.junit.After;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;
import org.springframework.mock.web.MockHttpSession;

public class UserInSessionVerifierExample {

 public HttpSession session = new MockHttpSession();

 @Rule
 public UserInSessionVerifier verifyUserInSession = new UserInSessionVerifier(session);
 @Rule
 public ExpectedException thrown = ExpectedException.none();

 @Test
 public void userInSessionPasses() {
   // Add user to the session.
   session.setAttribute("userName", "testUser");
   assertTrue(true);
 }

 @Test
 public void userNotInSessionFails() {
   // No user added to session
   assertTrue(true);
 }

 // This fails
 // - Because the exception is not returned by base.evaluate() but
 // by the verify() call in the Verifier class apply() method.
 @Test(expected = NoUserInSessionException.class)
 public void userNotInSessionUncaught() {
   // No user added to session
   assertTrue(true);
 }

 @Test
 public void userNotInSessionCaught() {
   // No user added to session
   thrown.expect(NoUserInSessionException.class);
   assertTrue(true);
 }

 @After
 public void removeUserFromSession() {
   if (session.getAttribute("userName") != null) {
         session.removeAttribute("userName");
   }
 }
}

Looking at this class you will notice that there are  2 JUnit 4.7 rules, 4 tests and an @After annotated method in it. Lets look closer at these aspects of the test class now.

The first rule declared is the UserInSessionVerifier rule that we implemented. We pass this rule the MockHttpSession as an argument to the constructor. This rule will be evaluated after each test is run, so if there is no user in the session at the end of a test the rule will fail verification. The second rule used is an ExpectedException rule which will be used to test that when the verification fails we actually recieve a NoUserInSessionException.

The 4 tests all contain a simple passing assertTrue(true) statement which means they should all run successfully. The difference comes in the verification state once the tests complete.  The userInSessionPasses test places a user into the session, thus when the verification rule is applied the state is verified and the test passes successfully. The userNotInSessionFails test does not place a user in the session and although the base statement passes the test fails due to the verification state.

The other 2 tests show how the NoUserInSessionException thrown by the  UserInSessionVerifier method gets handled. The userNotInSessionUncaught method shows that using the expected exception attribute to catch the NoUserInSessionException fails. This fails as the base evaluate method does not throw the exception – which is what the expected exception attribute checks. The exception is thrown by the verfiy method. Using the ExpectedException rule which catches exceptions even during the verification state we can catch this exception. The userNotInSessionCaught test passes as the ExpectedException rules expect method rule is met – the NoUserInSessionException is thrown.

The @After method simply clears the user from the session. As can seen this runs after the verification rule, otherwise the userInSessionPasses test would fail. I included it to test when the verification rule gets fired. I wanted to check that the rule was being fired before any clean up methods.

I belive that John could  update his verifier to check if a user was logged in based on the example presented here. I would be interested to know if he thinks such an implementation would prove to be scalable or not. Shall follow up with him.

Hopefully this has provided you with some ideas on how to use the Verifier rule. Would be great to hear about implementations of it you create and how it gets used. I shall move on to investigate the  TestWatchman rule  in my next installment, so hopefully you will be back for more!

GRRRR!! My IDE keeps crashing....

After several months of ‘garage’ Groovy and Grails development I have recently spent some time on a commercial Grails based project. This blog aims to share some of the issues I have had with IDE support during this project. I will endeavor to update this entry in the future based on my experiences.

My IDE of choice has been Eclipse for a number of years, but during the project I found reason to switch to NetBeans . The cause for this radical IDE change was the Groovy Eclipse Plugin constantly crashing my Eclipse IDE!

The Groovy Eclipse Plugin does have 2 versions. In defense of the plugin, I switched to using version 2 when working on the project, and updated my Eclipse installation to the Galileo release. This version is an alpha, and I had not had any issues with version 1 in previous versions of Eclipse. The plugin home page does state that both versions are working with Eclipse 3.5. I am certain that I checked this before installing version 2. Although as an alpha release I do concede that some instabilities are to be expected. I had also updated to the 3.5.1 release when the crashes became too much for me!

In attempts to stop the constant IDE crashes I tried several JVM argument updates and even took the more radical step of using a totally different JVM. With each attempt proving futile I decided to browse the Groovy Eclipse Plugin JIRA issues for more specific information. Here I found issues related to the Eclipse installation (GRECLIPSE-409, GRECLIPSE-413) I have and the Groovy Eclipse Plugin version I am using. (GRECLIPSE-417).

Nope..this one doesn't support it either!

On the recommendation of other team members I installed a version of Netbeans 6.7.1 which came with the Grails plugin installed. There are a quite a lot of things that I don’t like about the Netbeans IDE and the Grails plugin – but at the time of writing this blog entry – at least it is stable, doesn’t crash on me constantly and enables me to actually cut some code. Unfortunatly the Netbeans IDE is slow, the code completion is painfully slow (if it works at all), the Grails plugin hangs in the IDE and the interface is not as familiar to me (as Eclipse).

Thus, for the past week I have found myself using the a command line in a command window to build, run and test the Grails application – much as I did when using Eclipse during the ‘garage’ days. Stuck with an intolerably slow IDE with little to no code completion and frustrated by the whole development process. I am considering moving back to Eclipse and downgrading the Groovy Eclipse Plugin. (Any one got any suggestions/thoughs on that one?)

I throughly enjoy cutting Groovy/Grails code but would like a more productive IDE experience. I realize that a lot of IDE support is in alpha or beta status, but for Grails to gain some traction in the market place and with developers this support needs to exist.

I would love to hear about other peoples experiences with Grails IDE development. Information on plugins that I am unaware of or tips and tricks that would get me back up and running in Eclipse would be appreciated.

UPDATE – 10/01/2009

Almost a week has passed and there have been numerous comments on this blog entry, so I thought I would update it with my current status. I have removed all Eclipse instance from my working machine since the initial writing. These instances have been replaced by the Spring Source Tools (STS) 2.1.0 as recommended in the initial comment on this entry.

I have had several issues with this version – it seems to crash once I install the Subclipse plug-in as per versions of Eclipse 3.5.1. I had to reinstall the STS a few times during the week, but at times it has been stable and quite usable. As it still crashes I don’t consider this to be the end of my quest – so will be reviewing the comments that have been made and acting on them this week. I shall update when I have more information.

In order to simplify using these static methods add them to your Eclipse static import favourites. This little gem of functionality is found under Preferences -> Java -> Editor -> Content Assist -> Favorites.

Eclipse Static Import Favouries

In the above example I have added the org.junit.Assert.* package to my favourites. Now when I am working on some java code and want to use a static import from this package it will be available in the code completion box, as can be seen below.

Code Completion Static Imports in Eclipse

Acknowledgment for this simple tip and a few more must go to Benjamin Winterberg who provided this in his 5 Tips for Customizing Eclipse blog entry. Vote his entry up on DZone by voting here.  Hopefully this tip will make your Eclipse static import use a pleasure and not a frustration from now on.