Lots of community users have been asking about TorqueBox 4 recently, so it's probably past time to talk about TorqueBox 4 a bit and give a roadmap update.

For starters, the gem we've published as 'torqbox' and any references to that codename are being wrapped into TorqueBox 4.

We have a couple of high-level goals with TorqueBox 4:

• The various RubyGems we provide should be fully-functional libraries, usable just like any other RubyGem. No application server is required.

• Applications using our gems can optionally be deployed to a stock WildFly or JBoss EAP server.

Just RubyGems

TorqueBox 4 will no longer have a large .zip download or the large torquebox-server gem. Instead, we'll have a handful of smaller gems (torquebox-web, torquebox-messaging, torquebox-scheduling, etc) that can be added to any JRuby application.

Want to switch your JRuby application from another web server to TorqueBox 4? Just add 'torquebox-web' to your Gemfile, bundle install, and rackup -s torquebox.

Want to use our messaging and scheduling but something else for your web requests? Just add 'torquebox-messaging' and 'torquebox-scheduling' to your Gemfile, bundle install, and start using our APIs.

We provide an all-in-one set of components tested with each other that gets pulled in with the 'torquebox' gem. But, you're also free to pick-and-choose individual components if you don't want the full stack.

Application servers

If you need or want to use an application server, we'll still make it easy to run JRuby applications on top of WildFly and JBoss EAP. Applications written against our APIs will be able to go from running directly on the command-line to running inside the application server without changing the application or the application server. We'll take advantage of the application server to enable more advanced functionality when run inside of it, such as:

• web session replication
• load-balanced message distribution
• highly-available singleton scheduled jobs
• flexible cache replication
• multiple polyglot application deployments

Following along

If you'd like to follow along or contribute to the TorqueBox 4 development, it currently takes place on the torqbox branch. We'll be merging that to master before too long and will give a heads-up on the developer mailing list when that happens.

If you'd like to give TorqueBox 4 a try, for now you'll need to build from source on that branch. The README.md has instructions on doing so.

Once we get some incremental builds of TorqueBox 4 and its documentation published somewhere, we'll do another blog post that shows how to use those incremental builds.

Roadmap

TorqueBox 4.0 by mid-to-late 2014

We'll be putting out some 4.0 alpha / beta releases soon and hope to get 4.0 out by the middle of September. A lot of things will not be backwards compatible with TorqueBox 3.

At a minimum this will contain web, scheduling, messaging, and caching APIs. Each API may not exactly duplicate the features we have today in TorqueBox 3, but we'll add features where appropriate with each new minor release.

TorqueBox 4.1 by early 2015

The main focus of 4.1 will be easing the transition from TorqueBox 3. This means writing an in-depth migration guide as well as deciding what, if any, APIs we want to provide a backwards-compatibility layer for. Early adopters will be encouraged to migrate to TorqueBox 4.0 and provide feedback so we can make the migration as smooth as possible for everyone else in TorqueBox 4.1.

We'll also save time to add in some features missing from 4.0 that existed in 3.1, based on community feedback.

TorqueBox 3 in maintenance mode

We'll continue to fix bugs in TorqueBox 3 and put out releases as-needed, but don't expect any new features there. The tentative plan is to stop fixing bugs in TorqueBox 3 approximately one year after we release TorqueBox 4.

More to come

This was just a high-level overview of where TorqueBox 4 stands and what it will be. We'll be going into a lot more depth on various pieces in future posts.

Feedback welcome!

We welcome and encourage feedback from our potential users, current users, and especially our production users. Please get in touch if you have questions, concerns, or comments about TorqueBox 4.

As previously announced, we held a planning meeting on IRC to organize our activity beyond the forthcoming 1.0 release.

During the hour, the community created or updated over a dozen issues in JIRA to track the progress.

These include:

• WebSockets
• Infinispan for local caching
• Infinispan for distributed persistence
• Exposure of components via JMX
• CDI injection into Ruby components
• git push style deployment

and others exciting features.

The full meeting log is available.

If you missed this meeting, don't fret! Just surf over to JIRA and file some feature requests.

Since TorqueBox 1.0 has entered the release-candidate phase, we thought it would be good to begin some broad-stroke planning for life after 1.0.

Next Monday, 24 January 2011, the TorqueBox team will be having a planning meeting on IRC at 10am US-Eastern (1500 UTC).

Please stop by #torquebox on freenode to participate or simply observe.

During this meeting, we'd like to expand what "TorqueBox" means to include any place that Ruby might touch JBoss projects. Even outside of the TorqueBox AS environment.

Some rough ideas include, but are certainly not limited to…

• Infinispan client, ActiveSupport::Cache, ActiveRecord bindings
• Drools, jBPM integration
• ModeShape, Teiid

Please, drop by and help define the future of JVM-based Ruby.

Well, it's been over 4 months since 1.0.0.Beta19 was released, and three since the last blog post. I figured it's time to communicate with the community.

Jim Crossley has joined the TorqueBox team in the last few weeks, and has hit the ground running. Due to his efforts, later this week we'll see 1.0.0.Beta20 released, with a few minor bugfixes and update of JRuby.

Shortly after that (for some value of "shortly"), 1.0.0.Beta21 will be released, which brings about major changes, including being based off JBoss AS6 instead of AS5.

Additionally, we've been working furiously improving the HornetQ integration and providing ways to use smaller portions of TorqueBox as gems from arbitrary Ruby scripts.

We're nearing what we'd call "feature complete" for a good v1.0 release. We still aim to spend some time on…

• More unit testing
• Performance testing
• Packaging and distribution
• Ecosystem integration (capistrano, rake)

Longer-term (v2.0+), we'll be focusing on bringing in more advanced functionality such as transaction management to truly make Ruby "enterprisey".

Additionally, expect some cross-over from Marek's CirrAS project, to make TorqueBox in the cloud (EC2, etc) super simple and effective.