Подтвердить что ты не робот

Лучшая практика Maven для создания нескольких банок с разными/фильтрованными классами?

Я разработал библиотеку утилиты Java (аналогично Apache Commons), которую я использую в различных проектах. Помимо жирных клиентов я также использую его для мобильных клиентов (PDA с профилем J9 Foundation). Со временем библиотека, которая начиналась как единый проект, распространялась по нескольким пакетам. В результате я получаю много функциональности, но не очень во всех проектах.

Так как эта библиотека также используется внутри некоторых мобильных/PDA-проектов, мне нужен способ собирать только используемые классы и генерировать фактические специализированные банки

В настоящее время в проектах, которые используют эту библиотеку, у меня есть задачи Ant jar, которые генерируют (из проекта утилиты) специализированные файлы jar (например: my-util-1.0-pda.jar, my-util-1.0 -rcp.jar), используя функции задачи включения/исключения jar. Это в основном необходимо из-за созданных ограничений размера jar для мобильных проектов.

Мигрируя теперь к Maven, я просто задаюсь вопросом, есть ли какие-то лучшие практики, чтобы прийти к чему-то подобному, поэтому я рассматриваю следующие сценарии:

[1] - дополнительно к основному артефакту jar (my-lib-1.0.jar), также создающему внутри проекта my-lib отдельные/специализированные артефакты с использованием классификаторов (например: my-lib-1.0-pda.jar) с использованием Maven Jar Plugin или Maven Assembly Plugin, который включает в себя/включает... Мне не очень нравится этот подход поскольку он загрязняет библиотеку требованиями пользователей библиотеки (фильтры)

[2]. Создайте дополнительные проекты Maven для всех специализированных клиентов/проектов, которые будут "обертывать" "my-lib" и создавать фильтрованные артефакты jar (например: my -lib-wrapper-pda-1.0... и т.д.). В результате эти проекты-оболочки будут включать фильтрацию (для создания фильтрованного артефакта) и будут зависеть только от проекта "my-lib" , а проекты-клиенты будут зависеть от my-lib-wrapper-xxx-1.0 вместо my-lib-1.0. Такой подход мой взгляд проблематичен, так как даже это позволит реализовать проект "my-lib" (без дополнительных классификаторов и артефактов), в основном удвоит количество проектов, поскольку для каждого проекта клиента у меня будет один, чтобы собрать необходимые классы из библиотека "my-util" (проект "my-pda-app" ) будет иметь проект/зависимость "my-lib-wrap-for-my-pda-app" )

[3]. В каждый клиентский проект, который использует библиотеку (например: my-pda-app), добавьте некоторые специализированные плагины Maven для обрезки (когда создавая конечный артефакт/пакет) ненужные классы (например: maven-assembly-plugin, maven-jar-plugin, proguard-maven-plugin)

Какова наилучшая практика для решения таких проблем в "Maven way"?!

4b9b3361

Ответ 1

Общее правило Maven - "один первичный артефакт для POM" для модульности и причины, по которым не следует нарушать это соглашение (в целом), очень хорошо объясняются в Как создать два JAR из одного проекта (... и почему вы не должны) в блоге. Однако существуют оправданные исключения (например, проект EJB, создающий EJB JAR и клиентский JJB JAR с только интерфейсами). После этого сказал:

Указанный пост в блоге (также проверьте Использование Maven When You Can ' t Используйте соглашения) объясняет, как можно реализовать Вариант 1, используя отдельные профили или плагин JAR. Если вы решите внедрить это решение, имейте в виду, что это должно быть исключение и что это может привести к более сложному управлению зависимостями (и, как вы упомянули, загрязните проект с помощью "логики фильтрации клиентов" ). На всякий случай, я бы использовал несколько плагинов JAR здесь.

Вариант 2 не очень отличается от Варианта 1 IMO (за исключением того, что это отдельные вещи): в основном, N других проектов упаковки/фильтрации очень похожа на N правил фильтрации в одном проекте. И если фильтрация имеет смысл, я предпочитаю вариант 1.

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

НО, если толстые клиенты не, используя весь my-lib (например, серверный код потребует всего EJB JAR), тогда фильтрация не является правильным способом "maven", чтобы справиться с вашей ситуацией. Правильный путь был бы Вариант 4: поместить все в общий проект (создание my-lib-core-1.0.jar) и конкретные части в конкретных проектах (которые my-lib-pda-1.0.jar и т.д.). Тогда клиенты будут зависеть от основного артефакта и специализированных.