El empaquetado limpio de Java ha sido históricamente una tarea abrumadora. La falta de un estándar que aborde la ubicación física de los archivos en el sistema, sumada al uso común de términos de licencia que solo permiten la redistribución gratuita de componentes clave como parte de un conjunto mayor, ha propiciado el lanzamiento sistemático de aplicaciones autosuficientes con copias integradas de componentes externos.

Como consecuencia, las aplicaciones solo se prueban con las versiones de los componentes que las integran, un sistema Java completo sufre la duplicación constante de los mismos módulos, e integrar varias partes puede ser una pesadilla, ya que dependen inevitablemente de los mismos elementos, solo que con versiones diferentes y sutilmente incompatibles (diferentes requisitos, diferentes errores). Cualquier actualización de seguridad o compatibilidad debe realizarse para cada uno de esos elementos duplicados.

Este problema se agrava por la práctica actual de plegar extensiones en la propia JVM después de un tiempo; un elemento que podría integrarse de forma segura en una aplicación de repente entrará en conflicto con una parte de la JVM y provocará fallas sutiles.

No es sorprendente entonces que los sistemas Java complejos tiendan a fosilizarse muy rápidamente, y que el costo de mantener las dependencias actuales se vuelva tan alto que la gente básicamente se dé por vencida.

Esta situación es incompatible con la plataforma Linux, que evoluciona rápidamente. Para lograr el objetivo de un empaquetado RPM de aplicaciones Java intuitivo para el usuario y el administrador, fue necesario desarrollar una infraestructura personalizada y reglas de empaquetado estrictas.