Draft Roadmap

• 0.1 - current release
  • The 0.1 release provides a set of JMS Category APIs for community review
  • develop a wiki page that provide examples of the GroovyJMS usage
• 0.2 - next release - end of 2008
  • Adopt general Groovy style and standard, e.g. Logger
  • Add/replace with obivous and non-controversy Groovy-style API
  • Implement missing key JMS features, and list out any key JMS usage that have to use JMS API directly
  • Clarify possibly Groovy messaging usage
    • Check if it is possible to enhance Groovy Category to provide a pre-execute and post-execute API. This makes a big difference to the GroovyJMS API
    • Develop a wiki page with a table that list key JMS usage, current GroovyJMS API and proposed Groovy usage
• 0.3
  • Implement an optional Groovy Builder to construct JMS Connection Factory, and adjust default behavior.
  • Continuous to evolve and add Groovy-style API
  • Integrate with Grails JMS Plugin
• 0.5 - begin to evolve to a Groovy Messaging Service
  • that does not assume developers to have any JMS background, and do not expect developers to learn about JMS
  • Provide English language style / Domain Specific Language way for messaging.
  • Test and provide integration example for other JMS implementations / other messaging product
• 1.0 - Provide a full function Groovy Messaging Service as the standard way of using messaging enterprise Groovy applications
  • no assumption of JMS dependency
  • support non-JMS messenging functions such as Message Group, Virtual Topic as standard features

TODO List 

• Remove Log4j dependency and the MDC usage
• API Implementation
  • for send(), support Map and other type of JMS messages
  • for subscribe(), support closure with explicitly casting to MessageListener
• Naming convention
  • following JMS to use createQueue rather than queue()?  No, createQueue is for creating a Queue. For queue(), it isn't really just a Queue but a Queue with MessageProceducer functionalities