Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<h1>Draft Roadmap</h1>

<ul>
	<li>0.1 - current release
	<ul>
		<li>The 0.1 release provides a set of JMS Category APIs for community review</li>
		<li>develop a wiki page that provide examples of the GroovyJMS usage</li>
	</ul>
	</li>
	<li>0.2 - next release - end of 2008
	<ul>
		<li>Adopt general Groovy style and standard, e.g. JDK Logger</li>
		<li>First revision to Groovy-style API</li>
		<li>Provide API for all key JMS usages
		<ul>
			<li>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</li>
		</ul>
		</li>
		<li>Clarify possibly Groovy messaging usage
		<ul>
			<li>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 }</li>
			<li>Develop a wiki page with a table that list key JMS usage, current GroovyJMS API and proposed Groovy usage</li>
		</ul>
		</li>
	</ul>
	</li>
	<li>0.3
	<ul>
		<li>Implement an optional Groovy Builder for constructing ActiveMQ Broker, and adjust default behavior.</li>
		<li>Continuous to evolve and add Groovy-style API</li>
		<li>Integrate with Grails JMS Plugin</li>
		<li>Provide build script</li>
		<li>Full test coverage</li>
	</ul>
	</li>
	<li>0.5 - begin to evolve to a Groovy Messaging Service
	<ul>
		<li>No longer assume user to have JMS knowledge</li>
		<li>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.</li>
		<li>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 the new jms{ } usage is very clean and it's not really necessary to use annotation</li>
		<li>Provide English language style / Domain Specific Language way for messaging.</li>
		<li>Provide an example that demonstrate support for JBoss Messaging 2.0</li>
		<li>Benchmark the performance difference between implementing the project with Groovy and Java. Port to Java if there are significant performance difference</li>
	</ul>
	</li>
	<li>1.0 - Provide a full function Groovy Messaging Service as the standard way of using messaging enterprise Groovy applications
	<ul>
		<li>no assumption of JMS dependency</li>
		<li>support non-JMS features such as Message Group, Virtual Topic as standard features</li>
	</ul>
	</li>
</ul>

<ul>
	<li>Put the v0.1 source code to svn</li>
	<li>Remove Log4j dependency and the MDC usage</li>
	<li>API Implementation
	<ul>
		<li>for send(), support Map and other type of JMS messages</li>
		<li>for subscribe(), support closure with explicitly casting to MessageListener</li>
	</ul>
	</li>
	<li>Naming convention
	<ul>
		<li>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
 
 </li>
	</ul>
	</li>
</ul>

<h1>Status of JMS API Support</h1>

refer to the linked spreadsheet
<ul>
	<li><a href="http://www.editgrid.com/user/mingfai/GroovyJMS">http://www.editgrid.com/user/mingfai/GroovyJMS</a></li>
</ul>