Изменение конфигурации плагина для каждого дочернего модуля
У меня есть многомодульная сборка, которая содержит модули, которые могут быть нацелены либо на Java 5, либо на Java 6. Я хочу разрешить модулям выбирать Java 6, а по умолчанию оставить 5.
Чтобы установить Java 5 в качестве цели, мне нужно настроить следующее:
maven-compiler-plugin: Источник и цель установлены в 1.5
maven-bundle-plugin: настройте Bundle-RuntimeExecutionEnvironment на J2SE-1.5
Чтобы установить Java 6 в качестве цели, мне нужно настроить следующее:
maven-compiler-plugin: источник и цель установлены в 1.6
maven-bundle-plugin: настройте Bundle-RuntimeExecutionEnvironment на JavaSE-1.6
Я рассматривал наличие двух свойств: java.compiler.source и osgi.bree, которые могут быть определены каждым модулем, но это оставляет место для ошибки.
Как я могу переопределить конфигурацию этих двух плагинов для каждого модуля с помощью одного коммутатора?
3 ответов:
Как насчет того, чтобы разрешить дочерним модулям задавать свойство
my.java.version(или как вы хотите, чтобы оно называлось) и встраивать Заводной скрипт, который задает свойства версии для компилятора и плагинов пакета? Что-то вроде этого в Родительском pom:<project ...> ... <properties> <my.java.version>1.5</my.java.version> <!-- default Java version --> </properties> <build> <plugins> <plugin> <groupId>org.codehaus.groovy.maven</groupId> <artifactId>gmaven-plugin</artifactId> <version>1.0</version> <executions> <execution> <!-- set up properties in an early lifecycle phase --> <phase>initialize</phase> <goals> <goal>execute</goal> </goals> <configuration> <!-- this can be as simple or complex as you need it to be --> <source> if (project.properties['my.java.version'] == '1.6') { project.properties['my.compiler.version'] = '1.6' project.properties['my.execution.environment.version'] = 'JavaSE-1.6' } else { project.properties['my.compiler.version'] = '1.5' project.properties['my.execution.environment.version'] = 'J2SE-1.5' } </source> </configuration> </execution> </executions> </plugin> </plugins> <!-- now use the properties from above in the plugin configurations --> <!-- assume that both of these plugins will execute in a phase later than 'initialize' --> <pluginManagement> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>${my.compiler.version}</source> <target>${my.compiler.version}</target> </configuration> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <!-- sorry if this part isn't correct; never used this plugin before --> <instructions> <Bundle-RuntimeExecutionEnvironment>${my.execution.environment.version}</Bundle-RuntimeExecutionEnvironment> </instructions> </configuration> </plugin> </plugins> </pluginManagement> </build> </project>
Я бы лично структурировал ваш проект так, чтобы модули Java 5 происходили от одного родительского POM, а модули Java 6-от другого родительского POM.
Global Parent (majority of global settings) Java5 parent (just define source/bundle) module A module B Java 6 parent (just define source/bundle) module C
Я не думаю, что существует элегантный способ Maven для решения этого сложного сценария, ни ваше, ни предложенное Дунканом решение не являются легко ремонтопригодными IMO, когда количество субмодулей становится огромным.
Для максимальной ремонтопригодности, я бы написал сценарий оболочки (и / или пакетный файл на Windows) в случае, если Maven не может выполнить эту работу очень хорошо, например,
set-version.sh(иset-version.bat), который зацикливает все подмодули и сбрасывает свойства по умолчаниюjava.compiler.sourceиosgi.breeна основеversion-feed.txt,version-feed.txtдает вам один центральное место для манипулирования вашей версией варьирования. Как вы можете видеть, минусы в том, что это действительно не решение Maven, оно требует запускаset-version.shпередmvn ...каждый раз, когда требуется настройка версии.Кроме того, для стандартизации сборки / выпуска я бы использовал maven-enforcer-plugin , чтобы воспроизвести / приостановить процесс сборки на основе свойства
version.set(которое помеченоset-version.sh) и выдать некоторое предупреждение / Сообщение об ошибке, если разработчик не следует правильной процедуре при выполнении строить.version.setтакже дает гибкость, если вы предпочитаете использовать значения по умолчанию, определенные в каждом подмодуле, вместо запускаset-version.sh, просто установите его в true в Родительском pom.xml или из параметра командной строки.Пример структуры каталогов:
parent/ module-a/ module-b/ module-c/ ... ... pom.xml set-version.sh set-version.bat version-feed.txtНадеюсь, это имеет смысл.
Comments