Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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)
        { jmscode } to new JMS(){ jmscode }
      • 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 Factoryfor constructing ActiveMQ Broker, 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 No longer assume user to have any JMS background, and do not expect developers to learn about JMSUtilize Grape JMS knowledge
    • Use Grape/@Grab 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.
    • Implement an annotation that make a method bind to the GroovyJMS context transparently. so user needs not to use new JMS(){} and could directly use GroovyJMS resource and API
    • Provide English language style / Domain Specific Language way for messaging.
    • Test and provide integration example Provide an example that demonstrate support for JBoss Messaging 2.0
    • Benchmark the performance difference between implementing the project with Groovy and Java. Switch Port 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 features such as Message Group, Virtual Topic as standard features

...