Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-cactus Wiki" for change notification.
The following page has been changed by felipeal: http://wiki.apache.org/jakarta-cactus/GeneralDiscussions/Maven2Migration The comment on the change is: Added comments about J2EE versions and M2 profiles ------------------------------------------------------------------------------ * 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...) + + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
