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

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

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

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

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

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

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

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

Здесь два отдельных вопроса.

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

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

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

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

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

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

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

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