This wiki page discusses the maven 2 migration of Cactus.

Table of Contents

Problem

The current Cactus codebase is not maven-friendly. Since Cactus aims to support different versions of servlet spec (2.2, 2.3, 2.4), the current codebase is a little confusing (same class name but different implementations in several subprojects, e.g. j2ee-12, j2ee-13, j2ee-14), and there are circular dependencies among subprojects, which make the maven migration difficult.

Proposals

• To decouple the subprojects [Finished for framework main code; test code still needs decoupling]
• To re-organize the project structure in a maven-friendly way [Partly done]

• It will be great if Cactus was intellegent enough to detect automatically the servlet version. Take HttpServletRequestWrapper as an example. Maybe we don't need to provide one HttpServletRequestWrapper per servlet spec version. We may try to implement a generic HttpServletRequestWrapper that supports all versions. For methods which are not supported by the servlet spec (for example, getRequestURL() is not supported by version 2.2), just throw out an UnsupportedOperationException. Thus we may make a codebase that is cleaner and easier to maintain.

• Currently, the build is too slow because of Clover, Checkstyle and other checking. So, the new build should be fast by default (i.e, compiling and running unit tests) with the more complete reports and tests done by a different M2 profile.
• The samples should be separated M2 projects and run only by specific profiles (like integration tests and release). Also, if possible, they should automatically install as many containers as possible, using Cargo's zip-installer.

Comments

• Detecting the servlet version is a good idea; however it might require runtime access to the different servlet specifications. A general HttpServletRequestWrapper that works for all servlet specifications sound good. There's just one problem: it has to 'implements ...' a specific interface. The name of the interface is the same, but I'm not sure about the runtime checking - the jvm might detect that it's a different interface and throw IncompatibleClassChangeError or something similar. Since the differences between the code are minimal we can live with just one implementation that will be linked against the different servlet specifications. We can either re-link existing code multiple times or create empty subclasses in different projects.

• Regarding the decoupled projects, would it be possible to test the M1 plugin module using M2?
• Supporting multiple Java EE versions is really a nightmare. If dropping J2EE 1.2 supports eases the pain, I think we should give it a go. I'm also favorable to build Cactus using only one J2EE jar (in particular 1.4, which is available at ibiblio on geronimo-specs), but we must be careful not to use 1.4 only APIs on Cactus-13. Or we could simply create a unique cactus.jar that could be used by all J2EE versions (as much as we have automated tests that verifies it works with a couple of containers of each J2EE version...)