Должен ли я использовать плагины Eclipse (или пакеты OSGi) в качестве простого инструмента управления зависимостями?

Question

еще раз это произошло ... Я присоединился к новому проекту, состоящему из нескольких простых Java-проектов Eclipse, с взаимозависимостями, которые управляются через путь сборки проекта. Я нахожу это всего лишь хаосом. И когда дело доходит до запуска конфигураций - вы просто входите в ад.

В прошлом я старался создавать проекты плагинов вместо простых Java-проектов, даже если я никогда не собираюсь запускать эти проекты в виде пакетов osgi. Я просто считаю, что зависимости легче управлять в подключаемых проектах. Другие люди придерживаются того же пути? Что-нибудь против этого подхода?

Answer 1

Если вы читаете restructure of org.aspectj document, что проект сделал именно это:

• Все зависимости будут выражены в OSGi расслоения файлов манифеста, которые определяют путь к классам (для библиотеки банок) и «необходимые» пучки ,
  Библиотеки, ожидаемые или ожидаемые в среде развертывания (например, XML или JRocket), должны быть включены для целей сборки и тестирования, но исключены из продукта доставки. Они могут быть указаны как «необязательные» обязательные пакеты или как требуемые пакеты

• Начальная бинарная сборка будет работать через обычную сборку узлов, причем выход пакета, включая двоичные файлы из фрагментов пакета, которые он требует (но не из дополнительных комплектов)

Преимущество также включает в себя версии аспект OSGi, что позволяет определить минимальный и максимальный ожидаемый вариант зависимости.

Answer 2

Это звучит как интересный подход, но лично я считаю, что лучше всего управлять зависимостями построения с помощью внешнего инструмента построения, такого как Ant или Maven, вместо привязки вашей сборки к среде IDE. Если вы используете maven и плагин m2eclipse, он автоматически настраивает зависимости проекта Eclipse при загрузке Maven POM, если эти другие проекты также находятся в вашем рабочем пространстве.

К сожалению, если ваша команда в настоящее время использует управление зависимостями ad-hoc, маловероятно, что они захотят приложить усилия, чтобы перейти на Maven. Опять же, может быть, им просто нужен лидер, чтобы возглавить это усилие.

Answer 3

Я бы не использовал подключаемые проекты лично, я бы использовал инструменты построения, такие как Ant, Maven и другие.

Если система сборки не интегрирована, это означает, что компания не очень разбирается в разработке программного обеспечения.

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

Answer 4

Я думаю, что ваша методология, чтобы использовать OSGi для управления зависимостями, даже если вы не работаете в контейнере OSGi, очень звучит, потому что в конечном итоге это приведет к созданию более модульного кода. Модульный код проще реорганизовать и проще распространять среди нескольких разработчиков. Вам даже не нужно расширять классы OSGi, поэтому вы не создаете никаких дополнительных зависимостей.

С другой стороны, предложение Кен Лю использовать внешнее управление зависимостями также имеет свои преимущества, поскольку что-то вроде Maven будет обрабатывать большую часть зависимости и управления для вас.

Объедините два, и вы получите лучшее из обоих миров. OSGi можно заставить работать вместе с Maven с использованием дополнительных библиотек, таких как Bnd и m2eclipse.

Answer 5

Здесь есть две отдельные проблемы.

1. Как установить несколько проектов, и
2. Какая система сборки позволяет мне создавать несколько проектов

Два не должны быть связаны между собой. Так, например, вы можете выбрать Maven для создания проектов, но использовать проекты плагинов для облегчения редактирования. Большинство вещей избили систему сборки Eclipse; как только он начинает работать, он довольно стабилен - но получение его от ничего к работе предполагает (а) удачу и/или (б) черную магию.

В конечном счете возникает вопрос, к которому вам легче управлять; оба типа зависимости, или только один. Если вам нужен один, тогда вам нужно потратить время либо на что-то вроде m2eclipse (который генерирует зависимости проекта от MOV MOV), либо с помощью pax-construct (который может генерировать манифест из maven maven). Либо это, либо жить с двумя системами управления зависимостями.

Answer 6

Я согласен с тем, что в Eclipse легче управлять зависимостями проекта с помощью OSGi, чем традиционным способом добавления ссылок на проекты или библиотеки.

Однако, если вы продвигаете OSGi-путь управления зависимостями во время разработки, разработчикам необходимо будет изучить OSGi, и они будут стоить, поскольку они получат проблемы с видимостью класса.

Вы используете Require-Bundle или Import-Package для управления зависимостями? Несмотря на то, что Require-Bundle не является рекомендуемым выбором с OSGi, он может лучше подходить к точке зрения управления зависимостями времени разработки.

Если вы используете что-то вроде плагина Maven, Eclipse имеет раздражающее разделение совершенно разных методов компиляции/запуска внутри Eclipse и снаружи - с болью в поддержке двух параллельных систем компиляции/запуска.