Month: December 2008

Every now & then I need to whip out a quick webapp. Normally, I would prefer to use something like freemarker or velocity. But JSP is standard, and it’s everywhere. Despite it’s inability to be secure, it is convenient. And that’s gotta count for something right?

But, I never quite managed to get everything working. So whilst looking at tclogview, I figured it out. First of all, you have to get the dependencies correct.

  
    javax.servlet
    servlet-api
    2.5
    provided
  
  
    javax.servlet.jsp
    jsp-api
    2.1
    provided
  
  
    javax.servlet
    jstl
    runtime
    1.2
  

So you need to pull in both the servlet API and the JSP API. They’re both “provided” scope, which means that they have to be available when compiling, but they don’t need to be packaged as they’ll be there already. I’m not sure why you need the JSP API. When I was playing with NetBeans, it appeared to be necessary to get bits of the editor working correctly.

You also need to pull in the JSP Standard Tag Library. It’s not mandatory, but you won’t get far without it. The only trouble is that there are a gazillion different versions on the central repository with no clear clue as to which one should be used. This version appears to work OK. Importantly, it contains the taglib descriptors. Also, we set the scope to “runtime” as it’s not needed at compile time.

This gets you started. The other thing that you need is a correct web.xml. Different versions of the deployment descriptor get you different features in your JSP page. Go figure. Looking in the JSP spec right now, I can see §JSP.3.3.2:

The default mode for JSP pages in a Web Application delivered using a web.xml using the Servlet 2.3 or earlier format is to ignore EL expressions; this provides for backward compatibility.

The default mode for JSP pages in a Web Application delivered using a web.xml using the Servlet 2.4 format is to evaluate EL expressions with the ${} syntax. Expressions using the #{} are evaluated starting with JSP 2.1. See Section, “Backwards Compatibility with JSP 2.0” for more details on the evaluation of #{} expressions.

This caught me out for a while as I was trying to use the new syntax and it wasn’t getting interpolated. I want to use JSP 2.1, so I reckon it’s easiest to use servlet 2.5. That means I need a declaration that looks like this in my web.xml.

  
  
    …
  

Why was this a problem? Because the maven-archetype-webapp archetype generates a web.xml that looks like this.

  
  
    Archetype Created Web Application
  

Ooops. This issue was filed as ARCHETYPE-106 over a year ago. Fixing that would have made my life a lot easier.

I’ve ranted about Maven before. As it happens, I still stand by much of what I said. But, I’ve come to realise how superficial these criticisms are.

Earlier this year, one of the libraries that I have a hand in maintaining needed to be used by a maven project. Whilst I could have just written enough of a POM to specify my dependencies, I figured that it would probably be easier to just switch the build system to maven.

Plus, this particular library is meant to be used as a webapp. The existing ant build builds a war file. But really, the webapp is just for exercising the library, it’s not the main point. Switching to maven makes it ideal for splitting into two different projects.

So I went ahead, and made the change. I did it in a slightly invasive manner (moving my source directories around to fit the expectations of maven). But the end result is that I have found the project easier to work with. Previously, the dependencies of the project were very unclear. Switching to maven and running mvn dependency:analyze quickly spotted quite a few jar files we “depended” on weren’t actually used. And one of the nice things is that maven embeds the version number¹ in the resulting jars (previously it had been a chore to figure out what version was in use).

This turned out reasonably well, although the main benefits were yet to be had. These are down to the huge growth in the maven tooling ecosystem, particularly this year.

• Eclipse support has been improving by leaps and bounds. Initially I went with q4e (now IAM), but I later switched to m2eclipse as it seems to be a more fully-featured plugin right now.
• NetBeans has pretty good maven support, even though it’s lacking a couple of useful features in m2eclipse. But it’s also very nice as NetBeans is then entirely driven by the POM — it doesn’t create a bunch of files based on the POM. The POM is the project.
• Hudson makes it an absolute snap to get a maven project into continuous integration. Hudson is the only java project I’ve ever seen that comes close to the simplicity of a wordpress install. Way to go Kohsuke!
• The nexus repository manager makes using maven much more practical (even for a single developer) as it vastly speeds up downloads and reduces your dependency on central. Plus, you can use it as a place to deploy your own goodies once you’ve built them.
• Maven: The definitive guide — the maven documentation, whilst there’s a good deal of it, isn’t exactly integrated well. This book has been an enormous eye opener about how to do things “the maven way.” Plus the in-depth coverage of things like the assembly plugin was tremendously helpful.

With all these tools in place you find the integration really starts to come to the fore. For example, I noticed that hudson had a findbugs plugin. I installed the plugin in hudson, activated the findbugs plugin in my POM (about 4 lines of XML) and got:

• Pretty graphs of the number of bugs found in each build.
  
• Detailed breakdown of each findbugs report in each build, including source code views of where the problems lie.

  

• Indicators showing how many bugs I had introduced into each build (or hopefully removed).
  

In short, I got a lot of value out of a (relatively) small change. And the same technique can be applied almost identically on the next maven project. And the one after that. And so on. Consistency has been one of the great virtues of maven for us.

The end result is that now most of our projects are maven projects at work (and I’m also using maven at home).

Of course, it’s not all plain sailing. I’m still seeing something weird to do with m2eclipse and WTP. But I’m confident that I’ll figure it out and it’ll be fixed.

Overall, I reckon that maven is something you should be taking a look at if you’re building Java projects. I know some people had taken a look at Maven 1 and come away with a sour taste. Now’s the time to check back and see what’s changed.

¹ Even though I later had to change how this was done.