Wednesday, December 19, 2012

Planned updates to Impala in the near term

I am planning to do some overdue work on Impala in the short term to bring it up to date. The next release I am planning to do will be version 1.1. It will essentially be a maintenance release.

Apart from a couple of minor features still to be determined, the main focus will be on getting Impala working nicely with Spring 3.1 and Spring 3.2.

Right now, Impala won't run Spring 3.1 because of changes to the ApplicationContext interface, which introduced a getEnvironment() method. The changes to Impala to support this are very small, and will be made in this release. I also plan to use Spring 3.2 as the compile version.

I also intend to introduce changes to make it easier to add module-specific resources to a running application, which can be useful in providing on-the-fly template fixes in production.

Apart from this, I also intend to slim down the project significantly:
  • removing features that are no longer necessary, have been superseded, or are no longer supported.
  • removing old examples projects that I no longer intend to maintain.
I am also planning to all projects relating to OSGi support in Impala. As some will know, I experimented with introducing OSGi support to Impala, with some success. However, I also reached the conclusion it would take a great deal of work to make OSGi really usable in an Impala environment, work which I was certainly not interested in committing to. I'm quite happy to maintain Impala's status as a simpler alternative to OSGi, rather than a project which is designed to support OSGi directly.

Saturday, March 24, 2012

Impala 1.0.2 released

I am pleased to announce the release of Impala 1.0.2. This is primarily a bug fix release, but also contains some minor as well as more significant feature enhancements.

It's downloadable from the Impala downloads page. The jars will also be available shortly on the Maven central repository. 

Optional modules
It is now possible to express dependencies on optional modules. Module B may declare an optional dependency on module A, which means that if A is present, it's classes, resources and beans will be visible to module B. However, if A is not loaded, the application will not fail.

This feature makes it possible to allow optional functionality to be included in an application.

Module-specific library jars
This feature, described an earlier blog entry, allows a module to use third party library classes which are specific to that module. In other words, it allows a module to load it's own version of a particular third party library class, potentially one which is different from or conflicts with the class visible to other modules in the application.

In addition, this release covers a number of other issues. See the list of issues in this release.