Ответ 1
В этом конкретном случае архетип всегда может создавать все необходимые модули и перемещать различные варианты (набор модулей) в профили. Только один профиль будет активным по умолчанию, как указано во время шага archetype:generate.
Как таковой, если я хочу иметь набор модулей для aromA, я буду запускать архетип как
mvn archetype:generate -DarchetypeGroupId=.. -DflavorA=true
И архетип передаст эту переменную элементу activeByDefault профиля aromA, переопределяющему элемент modules для набора модулей, требуемых пользователями flavorA.
То же самое можно сделать и для flavorB и flavorB (например), каждый из которых определяет другой набор модулей.
Примером такого агрегатора/родительского ПОМ как части архетипа будет:
<profiles>
<profile>
<id>flavourA</id>
<activation>
<activeByDefault>${flavourA}</activeByDefault>
</activation>
<modules>
<module>profiled-module2</module>
<module>profiled-module3</module>
</modules>
</profile>
<profile>
<id>flavourB</id>
<activation>
<activeByDefault>${flavourB}</activeByDefault>
</activation>
<modules>
<module>profiled-module3</module>
</modules>
</profile>
<profile>
<id>flavourC</id>
<activation>
<activeByDefault>${flavourC}</activeByDefault>
</activation>
<modules>
<module>profiles-module1</module>
<module>profiled-module2</module>
<module>profiled-module3</module>
</modules>
</profile>
</profiles>
В файле archetype-metadata.xml можно указать:
<requiredProperties>
<requiredProperty key="flavourA">
<defaultValue>false</defaultValue>
</requiredProperty>
<requiredProperty key="flavourB">
<defaultValue>false</defaultValue>
</requiredProperty>
<requiredProperty key="flavourC">
<defaultValue>false</defaultValue>
</requiredProperty>
</requiredProperties>
И архетип, вызывается с опцией -DflavorB=true, затем генерирует pom следующим образом:
<profiles>
<profile>
<id>flavourA</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<modules>
<module>profiled-module2</module>
<module>profiled-module3</module>
</modules>
</profile>
<profile>
<id>flavourB</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>profiled-module3</module>
</modules>
</profile>
<profile>
<id>flavourC</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<modules>
<module>profiles-module1</module>
<module>profiled-module2</module>
<module>profiled-module3</module>
</modules>
</profile>
</profiles>
Такой подход имеет следующие преимущества и недостатки:
<сильные > Преимущества
- Вы сохраняете общие модули и обслуживание архетипа в одном централизованном месте, оставляя выбор вкусов пользователю архетипа
- Пользователи архетипа могут, при желании и с нулевой стоимостью, переключаться с одного аромата на другой, просто активируя/дезактивируя профили.
- Этот подход использует стандартные функции Maven.
Недостатки
- Каждый архетип будет генерировать весь набор модулей, хотя не все из них потребуются
- Если действительно "шум", пользователь может вручную удалить нежелательные модули, но все же это будет ручное действие.
Кроме того, помимо вышеприведенного подхода, мы могли бы также настроить Maven Clean Plugin в каждом профиле, чтобы удалить модули, не соответствующие его вкусу, так что при его первой сборке (a maven clean) любой не требуемый модуль будут удалены. Такой подход оставил бы POM с несогласованными профилями, хотя он мог бы также рассматриваться (не рекомендуется).
Что-то вроде:
<profile>
<id>flavourA</id>
<activation>
<activeByDefault>${flavorA}</activeByDefault>
</activation>
<modules>
<module>profiled-module2</module>
<module>profiled-module3</module>
</modules>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<filesets>
<fileset>
<directory>${basedir}/profiled-module1</directory>
</fileset>
</filesets>
</configuration>
</plugin>
</plugins>
</build>
</profile>