Зависимости построения в проекте библиотеки Java Eclipse для нескольких провайдеров - PullRequest
0 голосов
/ 02 сентября 2011

Мы пишем библиотеку JMS на Eclipse для использования в наших приложениях.Желательно, чтобы это работало со многими провайдерами JMS.

Поэтому мы строим наш код на основе интерфейсов Java и при необходимости создаем классы реализации для конкретного провайдера.

Что происходит с зависимостями сборки в подобных проектахкогда много людей работают над одной библиотекой, каждый над классами реализации для какого-то конкретного поставщика?

Скажем, у меня есть WebSphere MQ и я пишу код для этого поставщика.И еще один парень пишет для ActiveMQ.И другой для какого-то другого провайдера JMSДолжны ли мы все иметь соответствующие jar на наших путях сборки, или мы должны допускать наличие ошибок сборки для кода, написанного для других провайдеров.

Некоторые мысли, которые у нас есть: - включить провайдеровjars с проектом, - имеют отдельные задачи сборки ant, по одной для каждой IDE / программиста, - имеют специальный код поставщика в отдельных проектах / jars ???

Ничто из вышеперечисленного не выглядит для нас идеально.Любые рекомендации?

Спасибо, tpav

1 Ответ

0 голосов
/ 02 сентября 2011

Вы предоставляете интерфейс (или в этом случае вы используете интерфейс JMS), который определяется независимо от поставщиков - вы должны иметь этот интерфейс в своем рабочем пространстве, чтобы сделать ваш проект компилируемым. А во время выполнения вам понадобится поставщик, настроенный для привязки интерфейсов к текущим реализациям.

Чтобы достичь этого, вы должны иметь доступный интерфейс JMS в рабочей области. Для конкретных поставщиков я предлагаю использовать отдельные проекты (по одному для каждого поставщика), которые можно добавлять по мере необходимости для выполнения.

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

...