Ну, на самом деле официальный Java-способ упаковки исполняемого jar-файла заключается в размещении всех других зависимостей jar вне его, в папке, которая затем объявляется как находящаяся в пути к классам (либо в манифесте исполняемого jar-файла, либо какаргументы командной строки при запуске исполняемого файла jar).
Существуют инструменты, которые пытаются "вставить" ваши зависимости classpath в ваш файл jar.Они делают это либо распаковывая все jar-файлы (которые на самом деле являются zip-файлами с другим расширением), а затем перепаковывая все их содержимое в один jumbo jar.Или они добавляют jar зависимостей как есть во внутреннюю часть исполняемого jar.У Maven есть плагин, который делает обе эти вещи, и Eclipse может делать их тоже с ходу (когда вы экспортируете свой проект в качестве исполняемой фляги).
Я предпочитаю версию, в которой фактические фляги упакованы в вашембаночка.Во-первых, это более уместно при организации файлов, а во-вторых, вы не рискуете иметь два класса с одинаковым полностью определенным именем, которые изначально были помещены в разные банки, а теперь конфликтуют (по сути, один перезапишет другой).Более того, с точки зрения classpath, наличие нескольких jar-файлов в classpath, каждый из которых имеет свои собственные файлы классов, НЕ то же самое, что все эти классы помещаются непосредственно в classpath, поэтому добавление ресурсов в исполняемый jar-файл как jars (а не в виде файлов классов) это больше касается пересмотра этого.