Лучшая практика для JAR, связанных с различными средами

Question

У нас есть проект, который использует веб-службы, предоставляемые другой группой. Они предоставляют 3 набора JAR-файлов для веб-служб, по одному на каждую среду (Dev vs Test vs Prod).

Каков наилучший способ структурировать проект в Eclipse, который имеет разные JAR-файлы для Dev / Test / Prod? Вот о чем я думал:

• WEB-INF / lib <- все общие файлы JAR находятся здесь </li>
• WEB-INF / lib_dev <- только для JAR-файлов, специфичных для Dev </li>
• WEB-INF / lib_test <- только для специфичных для теста JAR </li>
• WEB-INF / lib_prod <- только для JAR, специфичных для Prod. </li>

Я могу использовать скрипт Ant для выбора общей библиотеки вместе с библиотекой для конкретной среды. Если я пойду по этой схеме, есть ли простой способ заставить Eclipse искать в lib и lib_dev по умолчанию (для создания WAR и компиляции Eclipse)? Или есть лучший способ создать такой проект?

Answer 1

На самом деле вы не должны создавать разные JAR-файлы для разных сред.

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

Однако, если вам действительно нужен действительно другой двоичный файл для ваших разработчиков, ваших тестеров (хм, насколько уверенно)Вы полагаете, что они смотрят на то же, что и ваши разработчики?) и, наконец, на производство (опять же отличающееся от того, что видели тестеры), тогда @Benoit Courtine предложила хороший подход.

Answer 2

Я думаю, что лучшим способом было бы использовать проект Maven в Eclipse (M2Eclipse) и репозиторий Maven (например, Nexus), который поддерживает ваши файлы jar.

Вы определяете в pom:

• общие зависимости
• три профиля (dev, test, prod), каждый профиль с соответствующими зависимостями.

Для вашей сборки вам просто нужноcall:

mvn -P dev/test/prod clean package

Это создаст вам войну с правильным WEB-INF / lib (общие зависимости + зависимости, специфичные для профиля).

Answer 3

Согласитесь с @Gary Rowe, и я добавлю, что несколько jar-ов кажутся глупыми для доступа к одной и той же веб-службе в трех разных средах. Единственное, что должно отличаться - это WSDL.

Это может быть легко достигнуто с помощью чего-то простого, например, аргумента виртуальной машины во время выполнения, который указывает, какой из них использовать, а затем включает все три в один и тот же файл. Мы делаем нечто подобное, когда у нас определен -Druntime.env (tst, dev, int, prod или local), что позволяет загружать соответствующую конфигурацию во время выполнения.

В качестве стороны - В нашем случае мы просто используем WSDL и генерируем код Java с maven как часть процесса сборки с Apache CXF. Фактические файлы JAR не требуются вообще.

Answer 4

Это действительно зависит от того, какую систему сборки вы используете, от «правильного» ответа. Нет смысла менять систему сборки, если она не сломана. Если вы используете что-то на основе сборки Eclipse PDE, хороший способ справиться с этой ситуацией - следующее.

Создайте проект для каждого из 4 баночек. Этот проект будет просто содержать jar на пути к lib и экспортировать содержащиеся в нем пакеты. 3 банки, которые зависят от общей банки, также могут добавлять импорт пакетов. Затем вы создадите 3 файла .product для сборки вашего программного обеспечения для каждой конфигурации, используя возможность экспорта .product.