in the following statement, can you explain the incremental builder in more detail?

"An incremental builder associated with your project automatically udates the module in a running platform instance whenever you make a change."

Wang

I believe the issue you are referring to is what we call "pinning". OSGi happily allows multiple versions of the same bundle (and the same packages) to exist concurrently. However, any one bundle, once it has been resolved, can be wired to only one version of a given package. Take for example the "spring orm" bundle. Lets suppose that version 2.5.5 of this bundle is wired to packages from version 3.2.6 of Hibernate. An application wishing to use Spring 2.5.5 and Hibernate 3.2.6 will be just fine. A second application wishing to use Spring 2.5.5 and Hibernate 3.2.5 however will not be fine – because the spring orm bundle can't be simultaneously resolved to both the 3.2.6 and 3.2.5 versions of Hibernate. We are looking at a solution involving transparent cloning of "pinning" bundles in scenarios such as this for future version of S2AP.

The title is slightly misleading, as the advantages you are talking about are only available when using the Spring Application Platform. OSGi provides the building blocks, but the extra sugar coating needed to make the whole experience smooth is provided by Spring AP.

It is obvious that you guys at Spring Source appreciate the value of modularity, and that you see OSGi as the way to achieve it. What is disappointing is that you not shown any interest in investigating alternative solutions which don't depend on OSGi.

The core Spring Framework has necessary features – support for hiearchical application context, a sensible startup and shutdown model, and declarative proxies – to support building a modular system. I started Impala (http://impala.googlecode.com/) initially just to see how far I could take these initial building blocks. The results are clear to me – with Impala you get a dramatically enhanced runtime and development model for Spring, a solution which works out of the box without any special runtime, build or IDE support, and without any modified third party libraries. In my opinion, a much simpler – albeit less perfect system – than is possible to achieve using OSGi. Gain without any real pain. The practical value in this approach is still obvious to me, and hopefully to you too.

I don't mean to criticise OSGi itself. I've learnt a fair amount about it recently, and it certainly appears a well thought through technology. However, it is undeniably complex, and when a lot of the drivers in our industry are pushing us towards simpler systems, I do questioning whether it is wise to push the entire development community en masse towards OSGi. Dealing with these complexities has forced you guys to embrace a more closed system than originally envisaged
(requiring GPL/commercial licence, OSGi with Equinox only, and not free tool support) – a movement away from the community-oriented spirit in which Spring software has been developed in the past.

All this being said, I anticipate a migration towards OSGi, and with Impala I intend to take advantage of OSGi, especially where it adds the most unique value – in third party class versioning.

In short, my verdict is well done for making OSGi accessible in a way which I thought not even you guys at SpringSource would be able to achieve. A thumbs down, I'm afraid, for not doing more to address the needs of the 90 odd percent
(not sure what the exact number is) of existing Spring users who are not using OSGi.

One of the best things about Spring in the past is making the best use of existing technologies in an open, practical way. The Java class loading model is far from perfect, but with a little creativity it is possible to build the key features
for a dynamic, modular system.

From what I can see, eclipse is one big failure. How can you possibly use eclipse as a shining example for OSGI given its shocking history for modularisation? It's terrible – plugin management isn't solved, its the PROBLEM in eclipse!

Anyway, the main negative I can see is writing and maintaining non-java code descriptors for EVERYTHING. Can I say EWW! This leads to huge runtime issues and the need to do integration testing.

[/quote]

"osgi", you don't have to use OSGi to use the platform – regular war file deployment is also supported, and we will look at providing support for the relevant JEE6 profiles once they have been defined.

In relation to Eclipse, the first mention of eclipse on this page comes from you! Eclipse retrofitted OSGi underneath an existing plugin model. As a result very very few Eclipse plugins take advantage of OSGi features such as the service registry that help plugins (bundles) to cope with dynamic changes in the Eclipse platform. The Eclipse extension registry (built on top of OSGi, but not part of any OSGi standard) does have support for notification of changes, but again very few plugins use this. I would argue that most of the issues surrounding plugin management in Eclipse are to do with the inability of plugins to cope with dynamic changes (forcing restarts), and the update manager itself.

Even though these issues exist, I believe Eclipse has still been an amazing success in terms of providing an ecosystem for third parties to integrate new components and capabilities. There are literally thousands of Eclipse plugins out there, and given the number of plugins and the rate of change, the whole thing stands up remarkably well.

On the second topic you raised, using the Application Platform tools for Eclipse your development time classpath is built from the manifests (in the same way as your runtime classpath) so you can catch any missing imports etc. early.