Saturday, May 10, 2008

Impala 1.0M1 released - first public release

I am pleased to announce the first public release of Impala, a dynamic module framework for Java enterprise application development.

Impala 1.0 M1 can be downloaded from http://code.google.com/p/impala/downloads/list

Impala builds on the Spring Framework to provide a genuinely modular, highly productive environment for web-based applications. It allows you to divide Spring-based applications into a hierarchy of modules which can be dynamically added, updated or removed to an existing running application.

Impala's modularity features make it possible to write applications which are much easier to maintain than plain Spring applications. Impala enables applications which can grow very large without exploding in complexity. Impala also enables genuine productivity enhancements over plain Spring development, through the dynamic module loading capability, seamless integration with Eclipse, and the efficient test management features. Impala also features basic built-in build support, based on ANT, and dependency management capabilities.

With Impala, you can take your Spring application development to the next level without having to grapple with any unfamiliar underlying technologies or tool sets. It requires no additional third party libraries beyond those required for plain Spring applications. It works within existing Java deployment environments, and requires no complex runtime infrastructure or tool support.

For more information on getting started with Impala, see http://code.google.com/p/impala/wiki/GettingStarted.

6 comments:

Anonymous said...

Great work!
Is there any plan to integrate with IVY for dependencies?

Phil Zoio said...

Hi Niko,

I wrote a few blogs about dependency management last September: see http://impalablog.blogspot.com/2007/09/simple-dependency-management-impala.html and http://impalablog.blogspot.com/2007/09/impala-ant-and-transitive-dependencies.html.

I did some experimentation with Ivy and decided to steer away from relying on transitive dependency management. The main problem is that you need to rely too much on the quality of the POMs in the various libraries. Another niggle - probably fixed by now - is that the released version of Ivy did not make it easy to download source jars.

Using Ivy with the SpringSource bundle repository looks like it might become an interesting option in the future: this is likely to fix the quality issues (as all the bundles are OSGi ready), but may not have all the libraries one needs.

Of course, there is nothing stopping you from using Ivy with Impala - there just isn't any built -in support at the moment.

OMax said...

Good work, should help (speed up) development very much.
Would use it if it were built on some standards and/or used maven2 for structuring modules and directories.

OMax said...

Checking out the trunk from svn... > 80 Mb of the jar hell reminds me time when there were no public jar repositories...
Guys why do you bloat your repository and hard drives with this?

Phil Zoio said...

Omax,

All of the dependencies are retrieved from public repositories, in particular, the Maven ibiblio repository. The distribution jar is less than 600K, including source jars.

The fact that dependencies are checked in to SVN is really just a convenience. If the size of the source is really a problem, then it would be straightforward to streamline this, with the extra step necessary to retrieve third party jars before you can start using the source. Feel free to raise an issue.

Regarding use of Maven, again this should be straightforward to enable, but not no work! I am hoping that someone will step forward and offer to do this work, as I am not a Maven user. I appreciate that as the project transitions from one which is useful to me to one which is useful to a wider range of users, this will be necessary.

Phil Zoio said...

Omax,

All of the dependencies are retrieved from public repositories, in particular, the Maven ibiblio repository. The distribution jar is less than 600K, including source jars.

The fact that dependencies are checked in to SVN is really just a convenience. If the size of the source is really a problem, then it would be straightforward to streamline this, with the extra step necessary to retrieve third party jars before you can start using the source. Feel free to raise an issue.