JAR Hell

Environments are populated from the system (boot) classpath, app server classpaths, application classpaths, and many more. The hierarchies of class loaders are increasingly complex, as are the environments they produce.

Although applications attempt to deploy their own dependencies, the vastly re-used and lower level packages (XML parsers and such) are often shared. Software components, inside applications, get whatever the application packager decided upon, combined with the deployment environment. Furthermore, operators deploy (more than likely unintentionally) into environments unexpected by developers.

In short, software runs in the environment it finds itself in, which is frequently not the same as that which it was developed or tested against. Such environments constitute vast unknowns, and such deployments/environments are inherently untested. This is no way to manage large or small software environments.

JAR-hell occurs when software is deployed into a runtime environment which is unsuitable, but nothing other than full integration testing would detect this. Having multiple software packages dependent upon the same piece of software, with unpredictable incompatibilities, is pure hell. Ensuring the compatibility of a variety of dependent packages is duanting, doing it amongst the variety supported by a hierarchy of complex class loaders, is inhuman.

Manual environment debugging is not something a human ought be forced to waste time upon, let alone every time they deploy. With that thought ... Depot Version was conceived.

Depot Version is designed to enable package versioning (and version introspection) to attempt to reduce JAR-hell through automation.