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 I would also like to invite community involvement in the project. The potential of Impala can only be realised with contributions from others in the developer community. If you're interested, take a look at this page: http://code.google.com/p/impala/wiki/GetInvolved Phil Zoio Impala Home: http://impala.googlecode.com Blog: http://impalablog.blogspot.com

Ok, here's a silly question. How is Impala similar to or different from OSGi? This question comes the perspective from someone who is in the middle of reading Joe's OSGI for Beginners article. :) Cheers, David Flux - Java Job Scheduler. File Transfer. Workflow.

From http://code.google.com/p/impala/wiki/QuestionAndAnswers

What about OSGi? OSGi is an interesting technology that allows for modularity and class version in Java application development. In the problems it tackles, Impala is in many ways quite similar to Spring Dynamic Modules, which is based on OSGi. While clearly a great technology, it is far from clear to me that OSGi represents the simplest, most practical way to solve the most burning issue which is affecting Spring developers on a day to day basis - the lack of a first class concept of modularity within Spring core, and the resultant difficulties in configuring large, complex applications. OSGi is a great solution for third party class versioning issues, but for me this is much less of a issue than the need for a simple, productive way of achieving modularity. Nevertheless, OSGi is on the Impala roadmap, at least as a area for further investigation. See this Impala Blog entry. There are those who would have you believe that you cannot have modular applications without OSGi. That is not the case.

That QuestionsAndAnswers page also had a link to blog entry that covers this topic more in-depth: http://impalablog.blogspot.com/2007/11/impala-and-osgi.html

From
http://code.google.com/p/impala/wiki/QuestionAndAnswers

What about OSGi?

...OSGi is a great solution for third party class versioning issues, but for me this is much less of a issue than the need for a simple, productive way of achieving modularity...

This implies that OSGi is just for class versioning issues (not just a third-party issue BTW) which is not the case. "a hierarchy of modules which can be dynamically added, updated or removed to an existing running application" is a good (but incomplete) description of OSGi. So the question still stands as to why one would choose a proprietary approach over OSGi when OSGi appears to provide the same functionality.

So the question still stands as to why one would choose a proprietary approach over OSGi when OSGi appears to provide the same functionality.

Agreed. Coming on the heels of S2AP, it seems like Impala has a big hill to climb to prove it's not Yet Another Framework.

Why does Impala include an Ant build system with dependency management capabilities? That sounds to me like, Maven. I think the real question is does Impala make things difficult for Maven built projects?