Thursday, May 20, 2010

Impala Code Jam in London in London on May 26th

Next Wednesday I will be holding an Impala Code Jam at Skills Matter in London, organised through the Java Web User's Group (JavaWUG). For the people who come along, this will be a hands-on opportunity to spend some time working on a simple Impala application and to get a better understanding of the concepts involved, and for most, to get a first hand flavour of how Impala can help in writing better, more flexible Spring based applications.

More details on the Code Jam are available from the JavaWUG announcement.

Wednesday, May 12, 2010

Some further comments on the 1.0 release

I'd like to make some comments about the timing of the 1.0 final release of Impala. As I've mentioned elsewhere, the aim of Impala is to extract every last ounce of productivity and flexibility out of Spring-based development, while at the same time remaining true to the principles that made Spring popular in the first place - simplicity and testability. I believe that with this release I can confidently claim that these aims are being achieved, and that Impala provides one of the most productive and flexible environments for building Spring-based applications.

Impala has been used in real world projects for almost three years. Over this period it has undergone extensive refactoring to ensure that the architecture is right - flexible, maintainable, and open to the kinds of extensions which are likely to be introduced in the coming months and years. After over 5500 subversion commits, I am pleased to say that I am comfortable that this goal has been achieved.

While Impala has allowed me to achieve unprecedented levels of productivity in projects in which I have used it, I have also been mindful that more widespread adoption requires adding support to commonly requested features, even ones not necessary in my own projects. Much of the effort put into the project in recent months supports these objectives. Impala now has decent support for Maven, and also allows for fully modularised web applications, including their constituent classes, JSPs and resources.

This work has gone a long way to extending the capabilities of Impala and offering a greater choice in the technology combinations that will work out of the box with Impala. This work is continuing. Nevertheless, I am now comfortable that the feature set in Impala is suitable for a 1.0 release.

I have really enjoyed developing Impala and look back on the work with a lot of pride. It has been a fun project, full of technical challenges. However, there is still plenty of work to do, and plenty of exciting areas to explore. To this end I would very much welcome more direct involvement from the community in helping the project to achieve it's potential. This involvement can take any form you might imagine, from testing the framework in different environments, to building a web site for the project, to adding tool support, through to working on new samples and even new feature set.

Impala 1.0 final released

I am pleased to announce the 1.0 final release of Impala.

Impala is a dynamic, modular productivity framework built around Spring. The aim of Impala is to extract every last ounce of productivity and flexibility out of your Spring development environment, while at the same time remaining true to the principles that made Spring popular in the first place - simplicity and testability.

Impala offers instantaneous redeployment of parts of your application, dramatically improving build/deploy/test cycle times. Impala supports on the fly 'drop-in' of new application functionality - including web modules - without requiring an application restart and without requiring any changes to existing application code or configuration.

With Impala you can achieve the productivity benefits of a modular approach to application development. When using Impala, you no longer need to work with application contexts which contain hundreds of bean definitions. Instead, you break your application down into smaller, manageable chunks. You no longer need to put up with the ever-increasing complexity and tangled interdependencies which come with a monolithic approach to application development. Instead, you develop your application in a loosely coupled way, with a clean distinction between application's interfaces and implementation components.

With Impala it is much easier to mix and match features for particular environments, which is particular useful for applications which may need to be deployed with different features and configurations on a per-environment basis. Writing integration tests with Impala is a doddle, because setting these up is simply a matter of selecting the modules you want to include in your tests.

Impala works with all the technologies you would expect in the Spring world - Hibernate, Quartz, JMX, etc. - without requiring any special plugins to be written for those technologies. It also supports - in most cases without modification - web applications using a variety of web frameworks, from Struts to JSF to Tapestry and others. A lot of work has been put into making Impala elegantly support modular web applications, allowing for modular vertical web application 'slices', rather than just a modular back end.

Impala works straight out of the box using a plain Eclipse installation (no fancy plugins required). It has a built-in build system which you can optionally use, based on Ant, and also integrates nicely with Maven.

With Impala, you can take your Spring-based application development to a new level of ease and sophistication, with remarkably few changes to the way you write applications.

See the full list of issues covered in this release.

With Impala 1.0 released artifacts are also available in the Maven central repository. See

If you like Impala and would like to support the project, please take a look at this page:

Sunday, April 25, 2010

Impala 1.0 RC4 released

I am pleased to announce the release of Impala 1.0 RC4.

Impala 1.0 RC4 was originally supposed to be the 1.0 final release. However, due to a few more than expected changes in this release, it was decided to have one last release candidate prior to 1.0 final.
The main changes in this release are:
  • simplifications and enhancements in the mechanism for mapping web requests to modules, allowing for more intuitive arrangements of JSPs and resources within modules.
  • modification of the starter application to use the multi-web module mechanism out of the box, as this is the recommended approach for building Impala web applications.
  • the addition of Javadocs to the build artifacts (this is now required for artifacts deployed to the Maven central repository via Sonatype's infrastructure).

For more information on this release see:

Phil Zoio

Impala Home:

Monday, April 5, 2010

Seven ways in which Impala makes Spring development more productive

Impala is a modular, dynamic productivity framework. The principal aim of Impala is to help developers extract every ounce of productivity out of the Spring development environment, while remaining true to the original Spring premise of simplicity and testability. The result is a much more productive Spring application development than you might think possible.

Here's how Impala lets you be more productive when working with Spring.

1. Virtually instantaneous build/deploy/test cycles

For typical Java applications, redeploying a change requires redeploying the whole application. Not with Impala. Only the affected parts of the application need to be deployed. This leads to virtually instantaneous build/deploy/test cycles, as the granularity of redeployment is typically very small relative to that of the application as a whole. You don't need to sit around for ages waiting for your whole application to load.

2. Automatic modification detection and redeployment

When you make a change to an Impala web application running in Eclipse, Impala can automatically pick up which parts of the application have changed, and redeploy those parts of your application without any user intervention. This removes the need for a manual step to perform this task. Impala gives you control over what resources are monitored for changes, how frequently resources are checked for modification, etc.

3. No explicit build step required

When writing typical Java web applications using Eclipse, in many projects there is an extra build step required to package your applications in order to deploy them. Not with Impala. Eclipse automatically compiles your classes for you incrementally in the background. The project structure conventions for Impala mean that this sufficient, and that no extra build steps are required during development.

Of course, you can do a regular WAR build when required for packaging for a production environment.

4. You can write your integration tests interactively

Writing Spring integration tests can be slow, particularly for monolithic single module applications. Impala allows you to write integration tests interactively. You can write and run integration tests using an interactive console within Eclipse. If making changes to your application between test runs, you simply redeploy the changed modules. If you're simply changing your test, you don't need to do anything special as changes to your test class will automatically be picked up on the fly. All of this leads to a much more rapid build/deploy/test cycle when writing integration tests than would be possible otherwise.

5. Suites including integration tests run super-efficiently

When running a suite of integration tests, modules needed by successive tests are loaded incrementally and remain available for subsequent tests run as part of the same suite. There is no need for continually starting and stop Spring application contexts, which can really slow down the execution of integration tests.

All of this makes test suite execution really fast, making Impala very friendly to use in environments where developers are expected (as they should be) to run the full project test suite before each commit to the version control system.

6. Setup is very simple

For a developer getting started on an existing project using Impala, it is really as simple as "check out and go" - simply check out the project files and starting writing and deploying the application within the IDE.

If you're starting a new project, this too is easy, as Impala provides a script which allows you to set up a simple, working application by executing a couple of commands.

7. Easy to use build and dependency management support if you need it

Impala works with Maven, but if you're not a fan of Maven, Impala also features a reusable build system which saves you having to write create your own build from scratch. Impala also gives you a simple way to pull third party library jars and source from Maven repositories, even if you aren't using Maven as your build system.

Friday, March 12, 2010

Impala 1.0 RC3 released

I am pleased to announce the release of Impala 1.0 RC3. Impala 1.0 RC3 is the final release candidate prior to the official 1.0 release. If no significant issues are raised against this released, it is envisaged that there will be virtually no changes in the subsequent 1.0 final release.

This release contains a number of enhancements:
  • simplifications making it easier to migrate existing Spring-based projects to use Impala. It is now possible to run Impala as part of an existing virtually unchanged traditional Spring web application, which should significantly simplify the task of migrating an existing Spring application to use Impala.
  • support for JSPs deployed within individual web modules. Prior to 1.0 RC3, JSPs need to be contained within the web application folder. With 1.0 RC3 it is now possible to completely modularise the web elements of a JSP-based web application.
  • support load time weaving of aspects created using AspectJ.
  • various other minor features and bug fixes.
Also, Impala 1.0 RC3 is available in the Maven central repository for the first time.

For more information on this release see:

In the next couple of weeks, I plan to add more documentation on how to get Impala working nicely with Maven, and how to migrate an existing Spring-based project to use Impala.

Please don't hesitate to report any issues you may encounter, which you can do on the Impala issue tracker:

Phil Zoio

Wednesday, February 3, 2010

OSGi and Enterprise Java dynamic modularity after Spring dm Server

The key message to be taken from SpringSource's decision to hand last month their Spring OSGi projects (Spring DM and dm Server) to the Eclipse foundation is the following: that OSGi is not ready for adoption by the mainstream of enterprise Java. Reality has finally dawned!

According the announcement from Adrian Colyer, CTO of SpringSource:
For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for mainstream enterprise application development.
While SpringSource will no doubt continue to support OSGi, the extent to which it will continue to provide resources to the donated projects is far from certain. What is more clear, though, is it will no longer be wielding it's own considerable influence within the industry to shepherd its user base en masse towards OSGi.

This is a good thing. Firstly, the obsession with OSGi has distracted the community away from practical efforts which could work more comfortably within the existing enterprise Java model. Hopefully that obsession will go away, or at least be limited to those already converted to the OSGi way. Secondly, from a purely selfish, egotistical point of view, I feel vindicated. For years, I have been saying that OSGi is too complex for the Java mainstream. For years, I have been beaten over the head by a small group of hardcore OSGi evangelists who have persistently used the argument that if SpringSource is betting on OSGi, then it must be a good thing for everyone else, and that any alternative approach does not warrant any consideration. The bet has failed, and this argument has now fallen rather flat. If SpringSource, with all the credibility it has generated through the Spring Framework, all its intellectual and marketing muscle, and all the effort and expense it has incurred, cannot make work OSGi for mainstream enterprise Java, then no one else can.

But all of this is also points to a real missed opportunity. The fact remains that Spring users still need a modularity solution. They need a way of being able to take advantage of the best of what dynamic modularity has to offer - dynamically composable software with genuine decoupling between parts of the application, and rapid build/deploy/test cycles during development - without having to take on all the complexity of the full-blown OSGi approach. This need still exists, and will not go away. As Adrian suggests, this need will not be served by OSGi without some fundamental simplifications, something I could not imagine happening any time soon.

In the meantime, I have invited SpringSource to engage more with Impala. While they have flirted with the idea in the last few months, perhaps even seriously, they have backed away from it for now. In view of recent history, it is not that surprising. Imagine the uproar that would ensue among the OSGi zealots if SpringSource were to go down that route. It doesn't bear thinking about.

Monday, January 4, 2010

Impala 1.0 RC2 released

I am pleased to announce the release of Impala 1.0 RC2. With this release, support for Maven is introduced for the first time, along with various other enhancements, refactorings and bug fixes, including:
  • simplifications to the default project structure, making it more intuitive and Maven-friendly
  • a dynamic properties Spring namespace, making it easier to support properties which can be injected and dynamically updated without requiring module or application reloads.
  • further refinements to the mechanisms for supporting multi-module web applications.
  • initial support for Spring 3.0.
For more information on this release see:

Phil Zoio