What is the difference between Equinox and Virgo?

Question

I'm sure I'll understand the difference as I start doing more stuff related to OSGi, but I thought it was a good question to ask since it's unclear to me from a couple quick Google searches. If anyone has a clear, concise answer…

Answer 1

An imprecise analogy: Equinox is the engine, Virgo is the car.

Equinox is the runtime from the Eclipse project (alternatives implementations include Felix (from Apache) and Knopflerfish).

Virgo uses Equinox at its core but provides many of the things one would require if using it in production. Virgo is basically the SpringSource dm Server project donated to the Eclipse Foundation, so it obviously has strong support for all things Spring. Many similar products exist (Karaf (ServiceMix) as well as numerous Java EE app servers).

An OSGi runtime is typically a very small (runtime) environment, just enough to launch/provide the OSGi framework. Products like Virgo offer the common production/enterprise functionality in a consistent, tested manner, and often include remote shell access, web-app support, security, etc.

You can work with a runtime directly, adding each feature as required, but while this may be useful for resource constrained systems, it's typically a lot of effort for little reward (apart from educational of course).

Answer 2

Technically, Equinox is the OSGi Framework and Virgo is the container. A container rides on top of a framework and adds functionality. The competing technologies to this are Felix and Karaf which are the Apache Software Foundation OSGi framework (Felix) and container (Karaf). The difference between the ASF offering and the Eclipse foundation offering principally that the Eclipse offerings are the reference implementation of the OSGI 4.2 specification.

The Virgo "subsystems" reference implementation is indeed a major improvement for the coordinated deployment of sets of bundles. In Karaf, they use a "features" deployment mechanism. The major difference between a "subsystems" and "features" deployment mechanism is that in subsystems you can segregate specific sets of libraries and keep thier packages from being used outside of a defined subsystem. With features all packages made available to other libraries are made available container-wide.