Лучшая практика знатока для генерации нескольких банок с различными/фильтрованными классами?
Я разработал библиотеку утилиты Java (так же к Apache палата общин), что я использую в различных проектах. В дополнение к толстым клиентам я также использую его для мобильных клиентов (КПК с профилем Основы J9). Вовремя библиотека, которая запустилась как единственный проект, распространенный по нескольким пакетам. В результате я заканчиваю с большой функциональностью, которая не действительно необходима во всех проектах.
Так как этой библиотекой также пользуются в некоторых мобильных проектах / проектах КПК, мне нужен способ собрать просто используемые классы и генерировать фактические специализированные банки.
В настоящее время в проектах, которые пользуются этой библиотекой, у меня есть задачи банки Муравья, которые генерируют (из служебного проекта) специализированные файлы банки (исключая: my-util-1.0-pda.jar, my-util-1.0-rcp.jar), использование включают/исключают функции задачи банки. Это главным образом необходимо из-за ограничений размера на сгенерированный файл банки для мобильных проектов.
Миграция теперь на Знатока, я просто задаюсь вопросом, существуют ли какие-либо лучшие практики для прибытия во что-то подобное. Я рассматриваю следующие сценарии:
[1] - дополнительно к основному артефакту банки (my-lib-1.0.jar) также генерирующий в моем-lib проектируют отдельные/специализированные артефакты с помощью классификаторов (исключая: my-lib-1.0-pda.jar), использование Плагина Банки Знатока или Плагина блока Знатока фильтровать/включать. Я не очень доволен этим подходом, так как он загрязняет библиотеку потребительскими требованиями библиотеки (фильтры).
[2] - Создают дополнительные проекты Знатока для всех специализированных клиентов/проектов, которые "перенесут" "мой-lib" и генерируют фильтрованные артефакты банки (исключая: my-lib-wrapper-pda-1.0... и т.д.). В результате эти проекты обертки будут включать фильтрацию (для генерации фильтрованного артефакта) и будут зависеть только от проекта "моего-lib", и клиентские проекты будут зависеть от my-lib-wrapper-xxx-1.0 вместо my-lib-1.0. Этот подход может выглядеть проблематичным с тех пор даже, который позволит неповрежденному проекту "моего-lib" (без дополнительных классификаторов и артефактов), в основном удвоит количество проектов с тех пор для каждого клиентского проекта, у меня будет один lib, только для сбора необходимых классов из "мой-util" библиотеки ("my-pda-app" проект будет нуждаться в "my-lib-wrapper-for-my-pda-app" проекте/зависимости).
[3] - В каждом клиентском проекте, который пользуется библиотекой (исключая: my-pda-app), добавляют некоторые специализированные плагины Знатока для обрезки (при генерации заключительного артефакта/пакета) классы, которые не требуются (исключая: плагин блока знатока, плагин банки знатока, прозащитный плагин знатока).
Какова лучшая практика для решения этого вида проблем в "Знатоке путь"?
1 ответ
Общее правило Maven - «один первичный артефакт на POM» ради модульности, и причины, по которым не следует нарушать это соглашение (в целом), очень хорошо объяснены в Как создать два JAR из одного Проект (... и почему не следует) сообщение в блоге. Однако есть обоснованные исключения (например, проект EJB, создающий EJB JAR, и клиентский EJB JAR только с интерфейсами). При этом:
В упомянутом сообщении в блоге (также проверьте Использование Maven, когда вы не можете использовать соглашения ) объясняется, как можно реализовать Вариант 1 используя отдельные профили или плагин JAR . Если вы решите реализовать это решение, имейте в виду, что это должно быть исключением и может усложнить управление зависимостями (и, как вы упомянули, засорять проект «логикой фильтрации клиентов»). На всякий случай я бы здесь использовал несколько исполнений плагина JAR.
Вариант 2 не сильно отличается от Вариант 1 IMO (за исключением того, что он разделяет вещи): в основном, наличие N других проектов упаковки / фильтрации очень похоже на наличие N правил фильтрации в одном проект. И если фильтрация имеет смысл, я предпочитаю вариант 1.
Мне вообще не нравится вариант 3 , потому что я считаю, что клиент библиотеки не должен «обрезать» нежелательные вещи. Во-первых, у клиентского проекта не обязательно есть необходимые знания (что обрезать), а, во-вторых, это может создать большой беспорядок с другими плагинами.
НО , если толстые клиенты не используют весь my-lib (например, для кода на стороне сервера потребуется весь EJB JAR), тогда фильтрация не будет правильный "способ знатока" справиться с вашей ситуацией. Правильный путь - Вариант 4 : поместить все общее в проект (создавая my-lib-core-1.0.jar ) и определенные части в конкретные проекты (которые будут производить my-lib-pda-1.0.jar и т. д.). Тогда клиенты будут зависеть от основных и специализированных артефактов.