Как динамически управлять зависимостями проекта - PullRequest
0 голосов
/ 16 марта 2012

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

В настоящее время все сервисы, расширяющие BaseService, являются частью одного и того же проекта (Eclipse + Maven), и некоторые сервисы зависят друг от друга, но поскольку они находятся в одном проекте, у нас нет проблема с зависимостями. Однако мы ожидаем, что будет написано 40-50 сервисов, которые расширят базовый сервис и также будут взаимозависимыми. Я беспокоюсь о том, что размер базового проекта будет огромным, и это только потому, что, когда кто-то должен использовать один сервис, он может зависеть от моего базового фляги, который имеет 50 сервисов.

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

Я слышал об OSGi, он решит мою проблему или есть способ, которым я могу сделать это с Maven, или есть более простое решение?

Извините за длинный пост!

Заранее спасибо за ваши предложения

Ответы [ 2 ]

2 голосов
/ 17 марта 2012

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

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

Вы также можете использовать OSGi для управления развитием вашего основного API службы через управление версиями;например, как вы сообщаете тот факт, что в API были внесены неразрывные изменения, а не разорванные и т. д.

1 голос
/ 16 марта 2012

Я бы сказал, что есть два варианта в зависимости от того, правильно ли я понимаю ваш вопрос.Первый.Вы уже определили интерфейс (термин Java), и теперь у вас есть различные реализации этого.Простым решением для Maven было бы иметь модуль, который называется, например: service-api, и затем он будет выпущен и может использоваться другими в качестве зависимостей.Со своей стороны они просто реализуют интерфейс.Нет проблем с зависимостями.Если вы больше говорите об OSGi, чем о Maven-Tycho.

...