Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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. JDK Logger
    • First revision to Groovy-style API
    • Provide API for all key JMS usages
      • In 0.1, the API support basic usage only. User has to use JMS API directly if they want to call certain JMS API that takes more configurable arguments. e.g. to send a Map message would require users to construct a JMS Message in v0.1
    • 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 Revised to use a Closure in Closure pattern, user code will be changed from use(JMS)
        Unknown macro: { jmscode }

        to new JMS()

      • 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
    • Provide build script
    • Full test case coverage
  • 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
    • Utilize Grape to provide underlying JMS implementation, by default Apache ActiveMQ, so users may have an option to use JMS without any special works to download JMS implementation jar files. JMS Implementation configuration could be done in the GroovyJMS Builder.
    • Provide English language style / Domain Specific Language way for messaging.
    • Test and provide integration example for other JMS implementations / other messaging product
    • Benchmark the performance difference between implementing the project with Groovy and Java. Switch to Java if there are significant performance difference
  • 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 

  • Put the v0.1 source code to svn
  • 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

  • No labels