Packaging Java JARs as RPM packages

· Read in about 2 min · (395 Words)

At JUDCon 2012, I had a discussion and argument with Jaikiran Pai and Ravi Maurya on «Packaging Java JARs as RPM packages».

Well it is not just RPM, it could be any package management system ( eg. dpkg, protage etc. ), doesn’t matter as long as it serves the purpose of:

  • automatic dependency resolution
  • installation of dependencies
  • rollback an install step
  • install multiple versions of a (JAR) package
  • ensure the packages are authentic ( for security )

How is all this achieved in Java world? Simple. Just package all the required JARs in a single JAR or WAR or an EAR for that matter. And trust the packager for its security. But:

  • Is this a good practice?
  • What happens when you want to install the same package on multiple systems?
  • Can you roll back changes easily on multiple installations?
  • How are JARs shared across different kind of projects, some which use the same version of the same JAR package?

Consider the case of Maven, with which you can easily specify the dependencies and Maven does all the work of dependency resolution. However, it solves the problem only at the developer’s level. JARs are still bundled inside the output application package (JAR / WAR / EAR). And everytime this application is distributed, it will contain «ALL» the dependencies. That is clearly an overhead.

That makes me think, why JARs don’t work like Shared Libraries, which can be shared across applications. Every classloader / JVM instance has its own version of the same JAR file on-disk! Can’t they be shared? That too is clearly an overhead. I am not aware of the reasons why it is so, which I would definitely like to know.

The point is, since a package manager has all the functionality, why not just leverage it? Java community is either unaware of it, or doesn’t care.

No problem. There are efforts already in place.

Anyway, of other things Jaikiran told me that, JBoss AS7 has how better and modular class loading which is based on JBoss Modules. This appears to me similar to how Maven structures it JAR repositories.

Here are some resources:

Thats it folks!