MANIFEST.MF in Plain Java, EJB, OSGi - catching the drift

While reading about OSGi, I realised how the importance of MANIFEST.MF has grown over time. The once only-a-jar-information file has had its ups and downs. When I was in school, *chapter jar* was an "assignment" / "reference". It wasn't worth a class' time spent on it. Today a whole new technology relies on this humble text file.

Past: Long long ago, in stone age (yeah I am exaggerating), the MANIFEST.MF was auto-generated while jar-ing. More or less it was not used. Well, yeah if you are developing a java application to be distributed to end-users (the jars you used to double click, which are so replaced by jnlp a.k.a WebStart apps now). This file would give a place to specify the class path

Manifest-Version: 1.0
Created-By: 1.4.2 (Sun Microsystems Inc.)
Main-Class: com.big.long.package.MyAppMain
Class-Path: mod1.jar mod2.jar lib/lib.jar

This will be set when running

java -jar myapp.jar

which other wise would have to be something like

java -jar myapp.jar -cp all_the_jars_to_be_in_classpath

Another *advanced* usage was in Applets. For an applet developer, to include modular jars in your applets' class path. (if you have one enough to make up its own jar, and enough that it is using custom or third party library jars;I am no more into applets but, replaced by jnlp too.. I guess? Or may be done soon. Look at JavaFX)

Near Past: Then came EJBs. These *were* soo cool! (Sorry you EJB lovers, if any, still reading this.. I Love Spring Beans). EJB spec emphasised MANIFEST.MF to level 2. The WAR files and EJB jars would share common librarys by packaging them in the same EAR and referencing them in MANIFEST.MF's class path. For example, a app-dto.jar is common to both app-web.jar and app-ejb.jar the EAR would contain a app.ear, app-web.war, app-ejb.jar, and app-dto.jar, the app-ejb.jar file would have a MANIFEST.MF that looks like

Manifest-Version:1.0
Class-Path: TradeInfo.jar

(And then, you know, Spring came and EJBs lost the war, people lived happily ever after.. :P But the MANIFEST.MF din't lives on..)

Now: we have OSGi which is basically only a spec. It defines some more metadata (headers) in this MANIFEST.MF. A Typical file looks like

Manifest-Version: 1.0
Bundle-Name: HelloWorld
Bundle-Activator: HelloActivator
Bundle-SymbolicName: HelloWorld
Bundle-Version: 1.0.0
Import-Package: org.osgi.framework

So to learn OSGi, all you need to learn is these headers and what they mean. This as you can realize by now is only metadata defined by the spec. The implementations will actually use these.

Future: MANIFEST.MF is not going anywhere. It is here to stay. Look at Equinox Extension for Eclipse Plugin development. It adds more headers like Eclipse-PlatformFilter, Eclipse-LazyStart. Spring dm Server adds its own functionality on top of Equinox, to features like bundle personality, library importing etc. There may be more of these coming. But all in the The very humble MANIFEST.MF we are talking about is silently delivering a new purpose.