И то, и другое можно использовать для достижения одного и того же: добавьте JAR в путь сборки.
Предположим, у вас есть проект P1, который хочет использовать JAR, установленный поставщиком S1, который находится в C: \ S1 \ aproject \ jars \ Useful.jar
Клиент Добавьте внешние JAR-файлы, перейдите, выберите, и все готово.
Но рассмотрим эти случаи.
1). Предположим, у вас есть несколько проектов, которые хотят использовать один и тот же JAR? Вы заканчиваете тем, что повторяли это для проектов P1-PN. Становится скучно Что еще хуже, предположим, что вы устанавливаете новую версию стека S1, теперь вам нужно обновить все пути сборки этих проектов до ссылки
C:\S1\aproject-**v2**\jars\Useful.jar
И что еще хуже, если вы пропустите одну из них, вы используете две версии JAR, которые могут быть очень плохими!
2). Вы делитесь проектом с коллегой, у которого продукт S1 установлен в другом месте. Теперь им нужно изменить проект так, чтобы он указывал на
E:\MyFavouriteThings\S1\aproject\jars\Useful.jar
И если вы используете SCM, вы можете наступить на пальцы друг друга.
Итак:
Вместо этого можно добавить переменную Workspace (т. Е. Специфическую для вашей среды), которую затем можно использовать для ссылки на этот JAR
$(S1_JARS)\\Useful.jar
Теперь у вас есть отдельное место для обновления до новой версии S1, и каждый разработчик может установить свое собственное значение для S1_JAR.
Я бы рекомендовал использовать Переменные для нетривиальных сценариев разработки.