1. Using the latest and greatest versions of everything.  Eclipse 3.4.  Hibernate 3.3.1.  Spring 2.5.6.  Tomcat 6.  Maven 2.0.9.  Java 6 ( 7? ), DWR 3.0.
2. Using Eclipse plugins to do as much as possible without causing headaches
3. Using as little XML configuration as possible – conventions, conventions, conventions!!!
4. Using JPA annotations for ORM classes.
5. Using Annotations for IOC dependencies.
6. Using Annotations for Transactional demarcation.
7. Using Annotations for MVC mappings.
8. Using very basic JSTL-based JSP’s for views.
9. Using Sitemesh to present a uniform look and feel across all pages.
10. For icing on the cake I’d like to also include GWT components.

Using the latest and greatest versions of everything
If you install Eclipse 3.4 first, and then install the Maven Integration plugin, it will greatly simplify things.  Just add Maven Integration to your project and then use “Add Dependency” option to quickly scour the entire repository and find the exact groupIds, artifactIds, and versions you want.  It also has a great view of the dependency hierarchy!  Getting all of these bleeding-edge versions to play nice together has its fair share of challenges.

Using as little XML configuration as possible

Using Eclipse plugins to do as much as possible without causing headaches

I already mentioned Maven Integration above to help with getting the LAGV of all the technologies being used.  Also of great value and import are SysDeo and  Subclipse.  Sysdeo is great for deploying and debugging your webapp in Tomcat.  Subclipse is great for seamless integration with an SVN repostiory.  Yes – use SCM on personal projects, you never know when you’ll need to revert or bring the code down onto a new machine.

But where do we draw the line here?  When do we have so much annotation cruft that an externalized xml configuration will seem like the ideal solution ( from whence we currently come in search of clarity! ).

Using very basic JSTL-based JSP’s for views
OK – well, tonight I was getting ready to put together the first couple of jsp’s now that the @Controller mappings are working and the pages are being served correctly.  I’ve got the method mapped correctly with @RequestMapping and I’ve got the model being put into pagescope with @ModelAttribute.  I’m ready to loop through a List using JSTL forEach.  But wait, can this possibly be true?  Tomcat6 has no implementation of JSTL.  JSTL 1.2 is the LAGV and the JSTL 1.1 is abandoned.  Only *Glassfish* ships with the reference implementation of JSTL 1.2?!?  Oh brother.  Thanks to Peter Mularien for writing a nice post informing me of this.

As if needing to download and install glassfish in order to get the JSTL 1.2 implementation jars for Tomcat6 wasn’t bad enough, well I hit a couple more snags after that.  First of all, I want to know who decided on the namespaces for JSTL 1.1 vs 1.2.  Here they are:

1.0  == <%@taglib prefix=”c” uri=”http://java.sun.com/jsp/core” %>

1.1 & 1.2 ==<%@taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %>

I mean all they did was add the “jstl” into the path?!?  I’m supposed to remember this?  OK – I’ll try harder to remember for next time.

Then, I learned that Maven2 doesn’t copy “system” provided jars into WEB-INF/lib by default and they need to be placed there manually as part of the project.  So, the appserv-jstl.jar I copied from glassfish wasn’t being included because I linked Maven to it as a system ( vs provided, or compile, or test, etc… ) dependency.