2015-09-25 9 views
0

Мне кажется, что было бы действительно полезно иметь зависимости jar, перечисленные в его манифесте, возможно, как необязательное поле. Без этой функции почти невозможно узнать, от чего зависит баночка, не найдя ее в Интернете где-то, или с помощью инструмента управления зависимостями, или что-то в этом роде. Теперь, когда все используют весь идентификатор артефакта, идентификатор группы, соглашение по версии, я бы предположил, что это значительно упростит инструменты, необходимые для настройки проекта.Почему нет зависимостей Jar, перечисленных в его манифесте

Мне нужно использовать maven больше, чем хотелось бы, потому что это такая проблема, когда вам нужно выяснить, есть ли что-то, что нужно для Apache или регистрации или что бы это ни было, почему бы просто не включить банки в каком-либо поле манифеста ?

+0

Вы спрашиваете, как вы можете добавить зависимости к манифесту, жалуетесь ли вы, что некоторые банки, которые вы нашли, не имеют его? – Tunaki

+0

Листинг зависимости могут быть приятными, но тогда есть зависимости зависимостей и т. Д., Поэтому инструменты, такие как Maven и Gradle, по-прежнему будут иметь свое место. – NickJ

+0

@ Тунаки вы говорите, что некоторые банки уже делают это? Я не встречал никого. – Snickers3192

ответ

1

Я думаю, что maven более удобен. Зависимости ссылок в манифесте очень неоднозначны, вы не указываете такие элементы, как группа, местоположение или репозиторий, даже если у вас нет безопасности для имени зависимостей.

Описание зависимостей в манифесте возможно, но как вы ссылаетесь на эти зависимости? Это зависит от каждого разработчика и, следовательно, может привести к использованию разных наименований, различной упаковки в банке и т. Д.

Maven более сложный, но также более сложный, поскольку он определяет репозитории, группы, артефакты, версию и пакеты, которые в конце помогает уменьшить двусмысленность и позволяет полагаться на надежную систему.

При использовании maven копия pom хранится внутри каталога META-INF, и здесь вы можете найти зависимости. Это более полезно, чем перечисление зависимостей в манифесте.

+0

Достаточно честно, я не имел в виду сделать весь проект таким образом, просто было бы легче для меня, если бы все банки были на центральном уровне, и я просто делаю быструю демонстрацию, не могу выставлять поп каждого время. – Snickers3192

+0

Не понимал, что там был пом. Это всегда так? Клянусь, я проверил, но, возможно, у меня был момент noob. – Snickers3192

+0

Всегда, чтобы проект управлялся с помощью maven – malaguna

1

Посмотрите на OSGI (http://www.osgi.org/Main/HomePage). Он обеспечивает, среди прочего, информацию о зависимости для пакетов (импорт и экспорт) на банке.

В целом: Зависимости обычно нелегкие и прямые (они могут различаться по объему, версии и т. Д.). Спецификация EAR и WAR от JEE попробует что-то подобное для серверов приложений.

+0

Если вы указали версию, однако они не должны отличаться, но спасибо за ваш ответ. – Snickers3192

1

Поскольку управление зависимостями сложнее, чем может показаться на первый взгляд, поэтому Java не предоставил механизм.

Если нужно было указать зависимости, для этого потребуется какой-то формат для описания каждой зависимости. Это должно быть имя плюс селектор версий.

Java - это кросс-платформа, поэтому имя не может быть именем файла, поскольку имена файлов не являются переносимыми. Это не может быть «имя» JAR, потому что некоторые реализации могут быть распределены по нескольким JAR. Имена должны быть уникальными. Кто это гарантирует?

баночка не может получить доступ к службе через абстрактную API, и поэтому может потребоваться требовать реализации, но не конкретных реализации. Как это будет выражено?

JAR может работать с несколькими версиями другого JAR. Как это будет выражено? Как бы вы указали, что это работает с целым рядом версий? Идентификаторы версий редко бывают номерами и поэтому не имеют очевидного порядка.