Entries in SpringSource Roo (6)

Saturday
Sep042010

Living on the Roo "edge" w/git

DateSaturday, September 4, 2010 at 12:06PM

Yep, I'm officially a writer - look I even have over 40 reading glasses on!Writing a book against a moving target is, well, moving.  Sometimes I just need to work with the latest Roo from git, to see where it's going.  For a while, there were incompatibilities in the STS Roo shell support that kept me from doing this, but with a little fudging around, I figured out how to do it for the unreleased 1.1.0.M4 line.

These instructions assume you have a working roo-dev shell, and are able to mvn install and use GIT.  Once you follow the instructions, you'll potentially have a working STS install that works against the GIT build of Roo, so you can watch progress between builds.

Do you need this? Well, no, maybe not.  

I do, since what I'm writing a book on depends on a somewhat rapidly evolving framework.  Speaking of the book, we are releasing another MEAP soon that will add another chapter, and also fix a lot of the wording, typos and other issues from the first four chapters.  Look for that soon, and thanks to everyone who is reading those MEAPs and participating in the review process.  We truly value you!.

Steps

  • First, get the latest code by using git pull
  • Make sure it builds, using mvn install
  • Make an assembly of Roo - this creates a zip install that you can unzip so STS can see it.  Do it this way:  mvn assembly:assembly
  • Take the file it creates in ./target/org.springframework.roo.root-1.1.0.M4.zip and move it somewhere, unzip it.  You now have a spring-roo-1.1.0.M4 directory with a distribution of the GIT code head.  YAY!
  • Decide whether you want to use this version on the command line as your regular roo.  I don't, I still use roo-dev.  
  • In STS, make sure you're using an external maven build - go to STS -> Preferences, search for Maven, add an external installation for 2.2.1 (which you've downloaded by now, I hope)
  • Also in STS, go to STS -> Preferences, search for Roo, and add this new 1.1.0.M4 roo installation, making it the default (don't forget to switch back if you don't like what you see).
  • Open your 1.1.0.M4 project, and if it doesn't automatically configure as a Roo project, just add Roo project nature and if you're still getting trouble, add the AspectJ Tooling feature too (from the Spring right-click project menu).

Sorry this is jotted down so hastily.  This is more of a note for me than everyone else, but I figured others could benefit.

One other note - if you somehow had a custom maven repo that you configured, check your Maven settings carefully.  I had to make sure my Maven install was correct.  Also, if you forget to mvn install the Roo dev build, it won't install the JAR files into your repository and you won't be able to build your projects.  

Enjoy!

 

AuthorKen Rimple | Comment2 Comments |
tagged , in
Thursday
Jun242010

Kickin' Butt with Spring Roo at the command line with Maven shade plugin

DateThursday, June 24, 2010 at 3:11PM
Note: I just noticed, maybe it's something just added in 1.1.0 or later builds, but they have the assembly plugin integrated with the Roo Shell perform command. So you can do perform assembly and actually get an assembled jar with all dependencies. WOOT. Anyway, this is still useful for those who want to run Maven headless projects.Let's say you want to use Spring Roo to do persistence work, but you don't need a website. Maybe it's just a utility, something that, say uses iText to generate PDF files, or does some data processing, job execution, or some other headless task.

Spring Roo is built using Maven, and the build target generally start in an initial Roo project by deploying a JAR file, until you add Spring MVC by adding a controller. In Maven, the output of a given build is generally one thing, (the jar) so running the project might involve downloading a ton of JAR files to add to a very big classpath. That's a lot of work.

Alternatives - Maven Packaging Plugins

There are a number of maven packaging plugins that can assemble a Jar that includes all of your classes and property files from various source Jars. Several, including the Maven assembly plugin, and the one-jar plugin, didn't work for me out of the gate due to some problems loading some of the SpringSource XML schemas and extender languages.

The challenge is that these special files, META-INF/spring.handlers and META-INF/spring.schemas, are included in each of the extension JARs (like Spring Security, Spring MVC, JMS, etc) so that you can issue commands like this:

<mvc:annotation-driven />

These tools generally copy files into a temp directory and then jar it up, so they overwrite these files each time.

The Shade Plugin

The Maven shade plugin has a nice feature called a transformer. There is a special AppendingTransformer class that can be configured to continue to append data into a file specified in the configuration. Based on this article from Hagel Blog, I added two entries to the plugin configuration (as commented below) to fix the two META-INF files and we were in business.

So, without further adieu, here are the steps to single-jar happiness (at least so far) with Spring Roo and the Maven Shade plugin:

Step 1: Install the Shade Plugin to your pom.xml file

Using your STS or favorite editor, go to your maven build file, pom.xml, and add the following entry to the build -> plugins section (THANK YOU, Hagel Blog, for figuring out the problem with Spring's namespace files!):

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-shade-plugin</artifactId>
  <version>1.3.3</version>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>shade</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
      <transformers>      
      <transformer implementation="org.apache.maven.plugins.shade.
             resource.AppendingTransformer">
        <resource>META-INF/spring.handlers</resource>
      </transformer>
      <transformer implementation="org.apache.maven.plugins.shade.
             resource.AppendingTransformer">
        <resource>META-INF/spring.schemas</resource>
      </transformer>
    </transformers>
  </configuration>
</plugin>

Step 2: Run your maven build

Now you can just issue a mvn package command, which will package up your content in the JAR file directly.

Step 3: Execute your JAR

Go ahead now and cd to target, and issue a command like:

java -classpath ./artifact-jar-file-name.jar package.path.and.mainclassname

And that's it. Pretty nifty feature, no? Let me know if you've had success or problems with this approach.

AuthorKen Rimple | Comment1 Comment |
tagged , in
Tuesday
Jun012010

Rod Johnson Speech at Philly JUG - Recap : It's Roo and Grails FTW

DateTuesday, June 1, 2010 at 7:15PM

Disclaimer:  I am a co-author of the upcoming Manning book, Spring Roo in Action, and a consultant for Chariot Solutions, a SpringSource partner.  That said, I'm normally not a cheerleader. These are my thoughts around the recent speech by Rod Johnson of SpringSource.  - Ken Rimple

Rod Johnson spoke last Thursday at the Philadelphia area Java User Group.  Although I got called away for a family matter at the end (darn!) I heard what I hoped to be the case: that VMWare has a strong interest in improving developer productivity, in general, for cloud computing and for mobile applications, and to that end, invested in SpringSource, which is also leading SpringSource to invest heavily in both Grails and Spring Roo.

I am a fan of both platforms.  Grails, with the Groovy language, is one of the best things to happen to dynamic programming on the Java VM in a long time.  With access to any Java library or framework, including the built-in Spring and Hibernate platforms, it gives new meaning to "Rapid Application Development."  

Spring Roo, on the other hand, solves the productivity problem more unconventionally.  Pop quiz:  when you hear the words "Aspect-J" and "Rapid Application Development" together, does it make sense?  Most people view Aspect-J as powerful and complicated.  While this is generally somewhat undeserved, Aspect-J, applied too liberally, can make a mess of an otherwise well-organized project.  Most junior to mid-level developers fail to grasp it, and senior developers usually apply it surgically to do some really great things.  Spring, in fact, uses aspect-oriented programming behind the scenes, when it does things like write dynamic Java Proxies to handle transaction management and security.

Roo is different because it uses a new feature of Aspect-J : Inter-Type Declarations.  Using Aspect-J class files, developers can weave features from various aspect files into a single class at compile time.  For example, Spring Roo Entities are comprised of at least four different class fragments - the entity class itself, with the fields of the entity, the JavaBean file, which contains setters/getters, the configurable, which adds the @Configurable annotation, and the Entity Aspect, which contains all of the methods to persist, find, query and remove entities from the database.

Rod's statement about how the Java platform has a short period of time to really take over the cloud computing industry was interesting.  He stated that Java developers are "really smart, and that's a good thing," and then something along the lines of, "The problem is that Java developers think they are really smart, which is a bad thing."  Probably paraphrased wrong, but rather hilarious.  He put a hypothetical scenario in front of us stating that, given a moderate problem to solve, a Java, Ruby and .NET developer would go about it different ways:

First, the  Ruby developer would get done on time.  The .NET developer would also finish, but the Java developer would have reviewed ALL OF THE OPTIONS and not necessarily have coded a single thing.  He says that is our problem, and that there are so many choices (a point I've argued a lot) that it makes it difficult for us to make decisions.  I've seen a great talk by Scott Davis years ago that mentioned the "tyranny of choice" - when our combinations of choices go up, we begin to 'vapor lock' and paralyze ourselves with decisions.  BTW because of Scott (and also Andy Hunt) there is a book on my reading list, "The Paradox of Choice."

So, we on Java have to get more rapid in our application development.  And hopefully, that's where Spring Roo leads us.  I developed on PowerBuilder back in the 90's for five years.  Why?  Because the alternatives for building business applications weren't so good:  VB 2.0?  terrible.  FoxPro?  What?  C++? Come on!  And then entered the web and Java, and we've been on the complexity train for a long time.  Spring has done a ton to make this easier, but we have to do better.   We must get to the point where it becomes trivial to boot up an application platform, to add persistence to our applications, to write a web application, to send emails, etc...  Grails and Roo should get us closer to that goal.

I left at the point where Rod was laying out the mobile strategy.  However, I see that Roo just got updated to 1.1.0.M1, which contains the starting point for building GWT applications (as well as Google App Engine back-ends).  It certainly looks promising for the 1.1.0 GA release.  But at least I think I've put decent bets on two good horses for rapid development on the Java platform with Grails and Roo.

Here's to what looks like an interesting 6-12 months on the Java platform.

 

AuthorKen Rimple | CommentPost a Comment |
tagged , , in
Tuesday
Jul142009

My Philly Spring User Group slides and zip on Spring Roo

DateTuesday, July 14, 2009 at 10:25AM

For those interested in SpringSource's Roo framework, here are the slides and zip file of a simple project I hacked around on with the tool.  In the slides I discuss a little about the internals, how Roo works overall, and what I see as the benefits of the platform once it matures.

I've been contributing with JIRA issues and forum posts on the SpringSource Roo forum pages, and the team has been outstanding in getting to issues.  One problem I ran into was fixed in 3 hours.  It definitely looks like SpringSource is pulling out the stops to build this framework, so watch for it over the next 3-6 months as it becomes more production ready.

 

AuthorKen Rimple | CommentPost a Comment |
tagged , in
Thursday
Jun182009

SpringSource Roo 1.0.0.M2 released, great blog post by Ben Alex on internals...

DateThursday, June 18, 2009 at 4:44PM

SpringSource just released Milestone 1.0.0.M2 of Roo, their developer productivity tool. It's 'getting better all the time', to quote a Beatles tune.

I was about to set aside some time to go over the internals of SpringSource's Roo and blog about it, but the creator, Ben Alex, beat me to the punch. Read his article on the SpringSource blog.

One interesting part of Roo for me is how you can start by scaffolding the UI pages, and then stop and manually customize things. There is an annotation on the Controller like this:

@RooWebScaffold(automaticallyMaintainView = true, 
   formBackingObject = Conference.class)

The key item here is the automaticallyMaintainView entry.  If set to false, Roo no longer generates and replaces the jsp code.  Which means that you can start by scaffolding the view, and then stop and customize it to your heart's content.

Also the Eclipse AJDT plugin apparently has a 'push generation' feature that will turn all aspect-driven code into actual classes, and remove your dependency on Roo altogether.  This is important, as you can use Roo to get started, get work done, and eventually part with it if need be.

Interesting stuff to watch going forward.

 

AuthorKen Rimple | CommentPost a Comment |
tagged , in
Page 1 2 Next 5 Entries ยป