Developing with Lightweight Plug-Ins
I'm always shocked at how little thought most architecture teams put into how easily developers can use their frameworks. EJBs are a perfect example of a spec that has academic merit, but whose real world development flaws make using it very expensive. With this in mind, I think it's always important to ask what sort of burden or impact a framework carries when it comes to the typical code/build/debug cycle.
In this way, lightweight plug-ins are pretty painless. Think of each plug-in as its own build-able project that simply depends on the core product's jars. This is very easy to model in a tool like Eclipse, where the core product has its own Java project and each plug-in has its own as well. You'd just need a final assembler project that depends on the core product and the various plug-in projects to include. By having the assembler project depend on the core and the plug-in projects, your classpath automatically will be built appropriately. The downloadable sample code includes a project layout like this. Keep in mind that you could have an assembler project for each customer, allowing you to combine plug-ins differently for different customers. This approach dovetails nicely with Eclipse, allowing incremental compiles and hot swapping of code during debugging. It keeps your development process agile by not adding build steps that stymie Eclipse's native Java support.
Is Everything Always a Plug-In?
One tenant of Eclipse is that everything is a plug-in (see "Sidebar 3. Comparison with Eclipse Plug-Ins
"). From the initial bootstrap of the system, to the Java development environment, to the online helpevery contribution of code (even if that code is not Java code) is modeled as a plug-in. This approach has its elegance, but it dictates an industrial plug-in development environment complete with tools for managing the components, debugger support, etc. To their credit, Eclipse provides this, but server-side frameworks with this level of support do not exist (to the best of my knowledge).
In server-side development, the established components of EJBs, JSP/Servlets, etc. don't lend themselves well to true plug-ins, which require real work to define and document an extension point. So treating everything as a plug-in would add significant work that probably wouldn't look very familiar to most J2EE engineers (a legitimate concern when trying to staff a team).
With that in mind, I try to use the plug-in concept as a tool to target specific areas of customization. As such, leveraging Spring to create lightweight plug-ins that seamlessly work with your existing application and technology makes them very compelling. For the most part, your application remains a fairly vanilla Spring/J2EE application. This is not a trivial accomplishment, as in-house frameworks often crumble under their own weight as lack of documentation and attrition make them more of a burden than a benefit.
You should also be aware of alternative plug-in frameworks. In particular, the Java plugin framework project comes to mind http://jpf.sourceforge.net/. A 10-minute tour suggests that it is based on Eclipse style plug-ins. I've never used this framework to see if it plays nicely with Spring and/or how much rethinking your application would require to adopt it. But if Spring-based plug-ins are too light for your tastes, this might be a nice option.