Как управлять зависимостями для инструментов поддержки проектов, таких как генераторы кода?

Question

Никогда не находил действительно удовлетворительного решения этой проблемы.Как ты делаешь это?Я ищу вдохновение для новых подходов.

Для контекста предположим, что я пишу генератор, который берет ресурс проекта и генерирует файл кода.Но это может быть любой другой инструмент поддержки проекта - валидатор, конвертер, развертыватель и т. Д. Часто запускаемые вручную действия, которые не выполняются как часть обычной сборки.

Для таких инструментов обычно требуется несколько зависимостей, которые не требуютсясам проект во время выполнения.

Стратегии, которые я применял или рассматривал в прошлом:

• в любом случае добавьте зависимость от проекта в проект и либо отметьте его как «предоставленный», либо отфильтруйте во времяпроцесс упаковки (это то, что я обычно делаю, но теперь я рискую добавить нормальный код проекта, который использует зависимость от инструмента, что может привести к ошибке, которая проявляется только во время выполнения)
• использовать скрипт (пытаясьтрудно избежать сценариев и их скрытых зависимостей и сложностей)
• создавать отдельные проекты поддержки (изо всех сил стараясь избежать взрыва проекта, особенно для, казалось бы, небольших задач, которые обрабатываются несколькими строками кода)
• подпроекты / модули (только смутно осознавая эту опциюn, никогда не пробовал)
• плагин maven, который запускается с профилем с отдельными зависимостями (пытается избежать отдельного проекта, необходимого для поддержки пользовательского плагина)

Вдохновение из ответови комментарии

• отдельный проект инструментов, совместно используемый несколькими проектами

Answer 1

Я только что понял, что maven и eclipse уже решили именно эту проблему для очень специфического «инструмента»: тестового кода.

Тестовому коду часто нужны дополнительные зависимости, не используемые самим приложением.

Очевидно, что люди вложили немало средств, чтобы сохранить инфраструктуру «test / tool» в одном проекте, в отличие от создания отдельного проекта test:

• отдельных исходных расположений (src / main / java,src / test / java)
• отдельные расположения ресурсов (src / main / resources, src / test / resources)
• полномасштабная отдельная область зависимостей maven "test", в комплекте с транзитивным разрешением
• отдельные этапы компиляции (компиляция / тестирование) с отдельными деревьями зависимостей
• eclipse поддерживает специальные конфигурации запуска junit, которые способны правильно разрешать тестовые зависимости
• возможно, больше вещей, которые яя не знаю в настоящее время

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

Я планирую создать и зафиксировать общие конфигурации запуска junit для команды, которая выполняет только один конкретный" тестовый случай ", который будет запускать логику инструмента вместо тестирования.

Проблема, которую я должен решить, состоит в том, чтобы не запускать эти фиктивные тесты во время обычной фазы тестирования maven.

Кроме того, когда я пишу это, я понимаю, что уже существует даже другая такая система: инфраструктура плагинов maven,это также имеет отдельный механизм разрешения зависимостей.Хотя пока что кажется необходимым или нормальным создавать отдельные проекты для создания плагинов.Я рассмотрю способы написания и создания конкретных подключаемых модулей maven без необходимости создавать отдельные проекты.Я думаю о создании pom.xml, необходимого для компиляции плагинов на лету, и включении всех тестовых зависимостей.