AppFuseRoadmap

This is version 23. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Spring 2004

• Implement Charles' persistent cookie strategy.
  • Status: Done
• Migrate to Ant 1.6 and Tomcat 5.x as primary testing targets, but don't go to JSP 2.0 (yet).
  • Status: Done
• Tie Managers to ManagerImpls using Spring. Possibly use Spring for some Hibernate enhancements and to tie DAOs to Impls as well.
  • Status: Done
• Re-arrange directory structure to be more inline with a 3-tiered architecture. Read Ideas...
  • Status: Done
• Add support for iBatis as a database layer choice.
  • Status: Done
• Updated Tutorials to reflect all of the above changes.
  • Status: Hope to complete in early March.
• MILESTONE: Release 1.4 - hopefully by mid-March.
• Add Spring as a web framework choice. Status: Hope to complete by end of March.
• Modify Cactus to create <runcontainer> tasks for all supported containers. Status: Not Started, here is the thread for implementing this.
• Figure out how to use MockStrutsTestCase to run ActionTests out-of-container. In-container is too slow.

Summer/Fall 2004

• Add WebWork as a web framework choice.
• Add Tapestry as a web framework choice.
• Figure out how to use Mocks to create faster unit tests, rather than just integrations tests (which is what exists now).
• (Possibly) Add JSF as a web framework choice.
• (Possibly) Add a Swing client that can talk to at least one of the above frameworks (if not all).

Thinking Out Loud: The hard part about adding "choices" for the user is that the CVS checkout becomes bloated and there are two many decisions. I'd like to figure out a way (hopefully using CVS) to allow a "default" version of AppFuse and then an AppFuse-WW, AppFuse-iBatis, etc. That's going to be tough to do because a lot of classpath's are going to change based on the implementation. It might be easier to simply start a new branch, but there's probably going to be a LOT of duplication between build files libraries. Maybe I can just split off the "lib" directory into another branch, and allow that to be download separately based on dependencies needed. Who knows. Is this something that Maven could make easier? I'd hate to get away from Ant, especially since I'm very comfortable with how everything works now.

Proposed Solution: I think the easiest way to handle the various "options" is to have them as a separate download and CVS module. Then I'll use ant in these modules to rip out and replace the core stuff with the module-specific stuff.

Implemented Solution: I'm adding all extra modules (i.e. iBATIS, WW, etc.) to the main CVS tree. Right now they're in the contrib folder, but I might move them to tools. For iBATIS (and the soon-to-come others), you just navigate to the contrib/ibatis directory (from the command line) and type "ant" to see your installation options.