AppFuseRoadmap

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

Spring 2004

• Implement Charle's persistent cookie strategy
• Migrate to Ant 1.6 and Tomcat 5.x as primary testing targets, but don't go to JSP 2.0 (yet).
• Tie Managers to ManagerImpls using Spring. Possibly use Spring for some Hibernate enhancements and to tie DAOs to Impls as well.
• Re-arrange directory structure to be more inline with a 3-tiered architecture. Read More...
• Add support for iBatis as a database layer choice.

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.