I got four days off for Turkey, PS3 games, goofing off with the family, and of course a chance to fiddle around with another framework. I saw a post on Wicket on InfoQ a few weeks back and it looked kinds of interesting as a possible replacement for some things I was doing with Spring on my labs site. My main problem with Spring is the resources required to do anything….and my lack of resources given my cheapo low budget hosting deal. Why write a blog page? Well inevitably these frameworks are written by super gurus who always seem to leave the little guy (part time hack-arounders like me) behind with the docs. A quick look at Wicket will leave a lot of people scratching their heads and asking – whaaa? How’d they do that?
What’s Required for Wicket?
Well any modern framework will require a bunch of stuff – you’ll need Eclipse (I’m using 3.7), Java 1.6.xxx, Maven, Subclipse, and the M2E plugin installed from the Eclipse site (not sonatype). Before doing anything I recommend getting the latest updates for all that stuff. Make sure you can run “mvn” from a command line while you are at it. It definitely helps to understand what Maven is and generally how it works. That’s pretty much it.
A First Test
The Quickstart on the Wicket site is a good first test, run thru this and see if all is well. Once you get the project downloaded with mvn and then added into Eclipse you should be able to start the internal server from the java class src/test/java/com.houseofbeor.Start.java file. Don’t forget to first stop anything running on 8080 or you’ll get a port conflict.
That seemed to work ok for me, but of course my next question would be how do I deploy that to a real server. More on that later since there is no mention on the Wicket site for how to do that. In the meantime there are a bunch of examples to play around with. You can see them on the Wicket site, but that’s not too much fun.
If you grab the source bundle then you can run them all locally. Extract the zip somewhere on your PC, then copy srcwicket-examples to a folder on your machine where you can mess with it using maven. Go to the root (wicket-examples) and execute a mvn build and then a mvn install. After that do a mvn eclipse:eclipse and you can add the entire thing to Eclipse as a project like with the Quickstart. You’ll notice after running the install that a .war file is dropped out for you. If you have a local app server you can deploy this to your apps directory and see everything local. Browsing thru the war packaging at least gives me some assurance that at the end of the day what you are deploying is a true war file…it also is a scary confirmation that maven is a useful tool that I know very little about since it has transformed the baffling development setup into a nicely organized war that deployed with no issues on my tomcat 7 server.
What’s even more impressive is that with the server up and running and clicking thru a bunch of the examples, tomcat is hovering, with a default config, in the 100 MB range – try that with a reasonable Spring or Seam configuration.
Deploying the App
The easiest way I found to deploy your app is to go back to the command line and do a maven install. This generates a complete war file that you can then drop into your app server. Works great.
Digging into the Examples and Rolling my Own
Starting at the top with the HelloWorld you can add these to your quickstart base. Here’s how I’ve done this:
To make it easy to browse the example code create a new Eclipse project from the code base you created above….ruh ro…no workie…I get build failures citing build path issues. Um – well there must be some problem with pom.xml, but I can see the build path is right – not sure what is wrong. Well – I can still browse around the code. I’ll fix this later….hmmm I smell something…pumpkin pie, turkey, sweet potatoes…time to go. I’ll post a Pt 2 with more interesting stuff on creating custom apps.
A bit on my system:
- 1. Latest JDK 1.6
- 2. Eclipse Indigo
- 3. Tomcat 7 – latest
- 4. Windows 7 -64 Bit
More to come…in Part 2.