Chariot Training Classes

Training Courses

I run Chariot's training and mentoring services. We provide training in AngularJS, HTML5, Spring, Hibernate, Maven, Scala, and more.

Chariot Education Services

Technology

Chariot Emerging Tech

Learn about upcoming technologies and trends from my colleagues at Chariot Solutions.

Resources

Chariot Conferences

Podcasts

Entries in spring-roo (25)

Friday
Sep202013

Hacking the 'Roo... Removing the default web plugins

Let's say you love the productivity of Roo up to a point, but that point happens to be the web. Unfortunately, the default Spring MVC patterns installed in a Roo web app are pretty heavyweight - adding localization, tiles, tags, jspx, etc...

If you ever set up and then backed-out a Roo configuration for the web, and then did the wrong thing and found it regenerated the default web site scaffold, you may have sighed under your breath that you just wish Roo didn't do that.

Well, you have an option. I'd say it's rather voodoo, but if you want to get prototyping in some web-based applications and just make a simple Spring MVC front-end, but don't want to get Roo involved in anything above, say, the service tier, here's what you can do:

  • Make a custom Roo installation directory
  • Expand Roo
  • remove the bundles for web, webmvc, web-json, gwt, jsf, selenium (and maybe one or two more I can't remember)
  • remove the cache directory from Roo (it copies the deployed add-ons into this cache as part of the Equinox OSGi container).
  • start up Roo, and see if it sends any OSGi errors your way. If it does, you've forgotten to remove a bundle. Try again - shut down the shell, follow the removal step, clear the cache directory, and restart.

There you are. Now, you can enjoy using Roo for the Aspect-J ITDs, and to make modeling data easier, but if you are simply using Spring MVC for a RESTful front-end, now Roo doesn't get in your way anymore.

You can always link your roo.sh shell script for this version of roo to something like /usr/bin/roo-lite.

Happy Roo'ing.

Ken

Monday
Jun172013

Spring Roo 1.2.4.RELEASE available now

Thanks to @alankstewart and some new contributors from the open source community, Spring Roo 1.2.4 has been released. It is available for download now.

Fifty issues have been resolved and it looks like the twitter tweet has been removed from the shell.

I'll be digging around with this a bit and posting any tidbits - I am also going to upgrade the code samples for Roo in Action to 1.2.4 this week, and will post any notes on what I find during upgrades.

Ken

Saturday
May042013

Spring Roo project updates...

It's been a while and all has been quiet on my front - I've been buried with day-job work, and enjoying not having to update a book in a while :)

A quick note on Spring Roo - looks like there are plans for a 1.2.4 release sometime in the summer. Alan Stewart tweeted this earlier in the week. Also, the Roobot, which accepts new OSGi bundles and also provides for downloading of existing ones, went down for a while, but due to some work recently by Alan it's up and running for internal bundles as of today.

If you're using Roo and need some basic Roo-provided bundles, they are now online.

Alan is working on getting the Roobot stabilized (some project descriptor might be causing trouble, we'll have to see which one - at one point it was mine). Once that's done they can re-populate the repository with the user-contributed ones.

Finally, the download link seems to be broken (the initial Download button works, but once you bypass registration and go to the download form, the real link is not a link), but follow my reply on this forum thread for a quick workaround.

Once Roo 1.2.4 gets ready for takeoff, I'll post my notes on it. I've recently submitted a contributor agreement to help Alan with some things here and there, and if they accept it, I'll be able to do a bit more for the community.

Thursday
Oct042012

More Spock love - how I tested complex install scenarios

I'm in love. Officially. With Spock.

Ok, we've only been hanging out for a little bit, here and there. But one of the things I'm doing is prepping for an updated talk on Spring Roo add-ons at SpringOne/2GX. Rather than repeat the same things again, I wanted to show some practical help for people writing add-ons, things like how to write good tests.

Also, I wanted to point out a few things that need more work, bring up some issues for the JIRA queue, so that we can improve Roo further after SpringOne. We'll get to that later in this article.

Testing add-on availability

Testing whether an add-on setup command is available to expose to the Roo shell can be a bit tricky. For example, in the Spock Roo add-on, I expect that the user's shell is:

  • running in a project context
  • the project has to contain two maven dependencies for spock-core and spock-spring
  • the project has to contain one dependency for the gmaven-plugin to run Spock tests

So, there are several scenarios to test. I started down the road to testing them all individually. Bad developer. First off, there is a sort of truth table here:

installedDependenciesinstalledPluginsexpectedResult
nonenonetrue
depa, depbnonetrue
depaplugintrue
baddepnonetrue
depa, depbpluginfalse
depabadversion, depbplugintrue

Given:

  • depa and depb = the correct two Maven dependencies,
  • baddep is a Maven dependency completely unrelated
  • depabadversion is the same dependency but a different version
  • plug-in is the gmaven-plugin from codehaus
  • expectedResult is whether or not we can go ahead and install the add-on (i.e. replace what is there)

As I started the third method I saw so much duplication I started to back off. First I removed whatever extra calls I was making to various methods (such as projectOperations.getDependencies()) which made it easier to test (and debug). Then, I pulled out the data table syntax.

Here is what I ended up with. Totally boss, BTW:

package org.sillyweasel.roo.addons.spock
import org.springframework.roo.project.Dependency
import org.springframework.roo.project.Plugin
import org.springframework.roo.project.ProjectOperations
import org.springframework.roo.project.maven.Pom
import spock.lang.Unroll

class SpockOperationsImplTest extends spock.lang.Specification {

  static def depa = 
    new Dependency("org.springframework", "spock-core", "0.6-groovy-1.8")
  static def depb = 
    new Dependency ("org.springframework", "spock-spring", "0.6-groovy-1.8")
  static def depabadversion =
    new Dependency("org.springframework", "spock-core", "0.6-groovy-1.0")
  static def baddep = 
    new Dependency ("org.springframework", "sbad", "0.6-groovy-1.8")
  static def plugin = 
    new Plugin("org.codehaus.gmaven", "gmaven-plugin", "1.4")


  @Unroll
  def "install check - #situation"() {
    given:
      def pom = Mock(Pom.class)
      def operations = new SpockOperationsImpl()
      def projectOperations = Mock(ProjectOperations.class)
      operations.projectOperations = projectOperations

    when:
      def commandAvailable = operations.isSetupCommandAvailable()

    then:
      1 * projectOperations.isFocusedProjectAvailable() >> true
      1 * projectOperations.getFocusedModule() >> pom
      1 * pom.getDependencies() >> deps
      pom.getBuildPlugins() >> plugins
      assert commandAvailable == res

    where:
    deps          | plugins | res   | situation
    []            | []      | true  | "no installedDependencies or installedPlugin"
    [ depa, depb] | []      | true  | "all installedDependencies...
                                      but no installedPlugin"
    [ depa ]      | [plugin]| true  | "some installedDependencies...
                                       and installedPlugin"
    [ baddep ]    | []      | true  | "a different dependency and no plugins"
    [ depa, depb ]| [plugin]| false | "all installedDependencies and installedPlugin"
    [ depabadversion, depb ] 
                  | [plugin] | true | "bad version of a plugin"
  }
}

What's even better...

See the method name at the top? It has an embedded hash mark, and uses the `situation` field, plus the `@Unroll` annotation, to turn the method into five separate test methods on the fly at test time. Niiiice!

Roo's challenges - addon testing

Why am I doing all of my testing in Groovy when Roo is a Java-based framework? Three reasons:

  • I want to get rolling on add-ons,
  • I need to understand the weaknesses of the add-on API so I can try to help improve it,
  • I need to make sure I test the most code for the least effort!

To the middle point: Roo is based on Maven and Spring. It manages a Maven `pom.xml` file, as well as Spring, Java and other artifacts.

Because the Maven files are managed by some Java wrapper classes, written for the purpose of generating Maven POMs, they are currently good enough - you can fill them via an Xml DOM, for example, but they aren't inherently testable.

For example, the Pom class can't be mocked, so I can't inject a fake set of dependencies or plugins. That is, unless I install two Maven test dependencies, both of which Spock told me to use as a helpful hint! They are: `cglib-nodep` for mocking interface-less classes, and `objenesis` for creating instances of classes as Mocks without no-arg constructors. To wit:

<dependency>
  <groupId>cglib</groupId>
  <artifactId>cglib-nodep</artifactId>
  <version>2.2.2</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>org.objenesis</groupId>
  <artifactId>objenesis</artifactId>
  <version>1.2</version>
  <scope>test</scope>
</dependency>

With that, I can use:

def pom = Mock(Pom.class)

See you at SpringOne/2GX

I'll be talking about this and other techniques at SpringOne/2GX in two weeks, and I'll post my presentation later as well. I hope to see some of you there.

Tuesday
Sep112012

My Roo add-ons talk at SpringOne/2GX is approved

Hello there. I'll be speaking about Spring Roo add-ons again at SpringOne/2GX this year. If you're heading to the show and want to talk shop on Roo and other things, seek me out. I'll be happy to chat.

Here is a link to the talk.