> Using 3.0 in a module might prove to be quite difficult. The main problem is > that they changed the artifactId from servlet-api to javax.servlet-api. This > makes it impossible to simple set a dependency management, you need to exclude > the dependencies on servlet 2.5.
I think you need to do this only if you will actually develop the atmosphere module, or will try to access some Servlet 3.0 new methods directly in the application. Not sure, though. > But even if you manage to do this in maven, > Eclipse still screws up your classpath and you will end up with duplicate > classes. Not if you exclude servlet-api from jetty's dependencies. > Personally I dont see why a framework released in 2012 still needs to support > servlet containers versions of over 5 years old. If you are able to upgrade > Wicket, you should also be able to upgrade other parts of your deployment. > IMHO Wicket should move forward with the rest of the world. Because supporting them costs virtually nothing? Because many of the framework users are still using 5 years old servlet containers? The infrastructure guys will happily deploy a new application with new jars (they probably don't even know what a jar file is), but won't take the hassle of upgrading all installed servers (and buying new licenses, and making new support contracts, and re-training all IT department) just because I want to use a new version of a third-party library. And well, the very first server with Java EE 6 support was Glassfish v3, in 2010. Tomcat and JBoss added that support only about a year ago. So, even if you are using a 1 year old server version, chances are you are still limited to Servlet 2.5! It's still too early to jump to the newest shiny thing.
