org.awesome.library -> org.repackage.org.awesome.library
Use this domain to break out of JAR Hell!

FAQ


What's the aim of this site?

The sole purpose of this site is to tell you that you can use the reverse domain name notation of this domain (org.repackage) as a prefix for your repackaged Java packages.


What's repackaging?

If you're on this page you probably know what repackaging is. But anyway:

Imagine that you want to add a library to your project that has a dependency to a library which you already use but in an incompatible version. Both library JARs occupy the same package namespace and depending on the Classloader one or the other classes are loaded. This is probably not what you want.

Now you have the possibility to repackage the incompatible JAR and referencing JARs. When you repackage a JAR you give some of it's classes a new package name (most of the times a prefix like org.repackage).

Still you have to know what you do (e.g. Reflection, Licensing).


Which Tools can I use for repackaging?

Most common tools in use are:


Are there alternatives to repackaging?

Common alternatives are:

  • Don't use the same in library in different versions / Don't let your tool users add own libraries.
  • OSGi

Which new package name should I chose?

It is common to prefix the existing package name with another domain like org.repackage in reverse domain name notation. It is not recommended to completely hide the original package name.

Since some meta information is lost when repackaging it's useful to include the library version in the new package name. Due to some limitations when naming Java packages (no hyphens, no numbers at the beginning) it could look like this: org.repackage.v1_0_0.org.awesome.library

Famous Repackaged Libraries In Action


Sun/Oracle Java (repackaged Apache Xerces)

Google App Engine SDK (repackaged ANTLR, Joda-Time, ...)