Проблема, для которой я не могу найти красивое, масштабируемое решение:
У меня есть проект, который предоставляет несколько вариантов данного артефакта. Это было создано как многомодульный проект, в настоящее время с 3 модулями:
- /flavor1_module
- /flavor2_module
- /flavor3_module
Дело в том, что у меня есть еще 50 проектов, которые нужно настроить таким же образом, т.е. предоставить 3 варианта.
Рассматриваемые решения:
- turning the already created multimodule project into a parent for all other 50 projects
- Cons: It just doesn't work. The instructions kept withing parent's modules are not inherited, thus they are not executed.
- using maven-archetype-plugin to create a multi-module project
template, and then creating all 50 projects based on the template
- Cons: if I would need flavour4, I need to manually update all 50 projects to add flavour4_module (and duplicate its content). Not scalable.
- embedding the configuration of all flavours into a single pom and enable or disable them based on profiles (i.e. using composition by profiles instead of inheritance via modules). Then pointing the 50 projects to it, as their parent. This would create "inline" modules
- Cons: I would need to implement on my own mechanisms which are provided by modules out of the box. (e.g. building every flavour in a separate directory). I would also lose the clear seperation that modules provide.
Любые идеи, как сделать это красиво? Есть ли другой вариант?
Спасибо, Лукаш
Изменить:
Другим вариантом может быть расширение maven-reactor-plugin с помощью < em>reactor:inject-modules, которая загрузит определение модуля из внешнего артефакта и прикрепит его определение как обычный модуль. Это создаст новый модуль на лету. Тогда все 50 проектов могут сделать этот pom.xml своим родителем.
Конфигурация будет выглядеть так (черновик):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-reactor-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>inject</id>
<phase>initialize</phase>
<goals>
<goal>inject-modules</goal>
</goals>
<configuration>
<modules>
<module>
<artifactId>flavour1_module</artifactId>
<groupId>[ groupId ]</groupId>
<version>[ version ]</version>
</module>
<module>
<artifactId>flavour2_module</artifactId>
<groupId>[ groupId ]</groupId>
<version>[ version ]</version>
</module>
<module>
<artifactId>flavour3_module</artifactId>
<groupId>[ groupId ]</groupId>
<version>[ version ]</version>
</module>
</modules>
</configuration>
</execution>
</executions>
</plugin>
Имеет ли смысл идти по этому пути?
Обновление:
Написание плагина, который манипулирует списком модулей для выполнения (идея внедрения модуля, которую я описал выше), кажется невозможно реализовать, потому что модули обрабатываются ядром maven, а механизм не предназначен для расширения с помощью плагин. Это подтверждается тем фактом, что оба плагина выполняют одинаковую работу, то есть манипулируют списком выполняемых проектов:
сделайте свое дело, выполнив системный вызов для создания дочернего процесса maven. Для меня это не выход, потому что это очень нестабильное решение. Действительно, maven-reactor-plugin стал несовместим с Maven3.
maven-invoker-plugin по-прежнему выглядит многообещающе. Плагин изначально был разработан для запуска интеграционных тестов, но его можно было бы использовать для расширения, например. этап компиляции. Но для этого требуется, чтобы дочерние pom.xml-s рассматривались как ресурсы и изменялись на лету. Для проблемы, которую я здесь описал, решение было бы слишком сложным и нестабильным. Я бы предпочел что-то более легкое, что могло бы работать в памяти при построении модели maven.
Поэтому пока использую профили, стараясь сделать их максимально компактными. Вероятно, через какое-то время мне нужно будет снова подумать над проблемой.
