Skip to main content

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
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.

Popular posts from this blog

Being a Vegetarian

I am a Proud Vegetarian. I don't eat Meat or Eggs. People say its hard here in US to be one. I beg to differ. The mere fact that I am hail and healthy these 4 years is a definitive proof. Apart from being bullied and trash talked by The Meat-Eaters, There is really nothing that makes this choice of mine any more than a debatable issue at a lunch or dinner. Other things aside, I am writing this blog having watched a PETA Video. Before you click on the play button, I ask you - If you are a vegetarian : Dont watch it. If you are not : Dare to watch it till the end. If you think going veg is just a fashion, think again . Even if you just want to do it for Fashion . Do it. Go Vegetarian. And Feel better asking the waiter for a Vegetarian Entrée in your next lunch.

Using Equinox CommandProvider to make OSGi console interactive.

After fiddling with the First Bundles that "Hello World"-ed upon Activation, You want to see more interactivity in OSGi. Although Using OSGi for an interactive Command Line Application would be like this one would be, well, a callable over-kill, I am going to start with an example and Expand it in later posts. So, please Welcome CommandProvider. CommandProvider is an EQUINOX specific API for extending the Console. This basic Example illustrates how to get a command from console and do something in java and also gets your feet wet on Service Registry package; import org. eclipse .osgi.framework.console .CommandInterpreter; import org.eclipse.osgi.framework.console.CommandProvider; public class DisplayMessageCommand implements CommandProvider { public void _say(CommandInterpreter ci) { ci.print("You said:" + ci.nextArgument()); } @Override public String getHelp() { return "\tsay - repeats what you say\n"; } }

How to Make a Local (Offline) Repository in Ubuntu / Debian

If you are in a place where you dont have internet (or have a bad one) You want to download .deb packages and install them offline. Each deb file is packaged as a seperate unit but may contain dependencies (recursively). apt-get automagically solves all the dependencies and installs all that are necessary. Manually install deb files one by one resolving each dependency would be tedious. A better approach is to make your own local repository. Before you actually make a repo, You need *all* deb files. You dont practically have to mirror all of the packages from the internet, but enough to resolve all dependencies. Also, You have to make sure, you are getting debs of the correct architecture of your system (i386 etc) # 1. make a dir accessible (atleast by root) sudo mkdir /var/my-local-repo # 2. copy all the deb files to this directory. # 3. make the directory as a sudo dpkg-scanpackages /var/my-local-repo /dev/null > \ /var/my-local-repo/Packages # 4. add the local repo to sour