Вопрос по – Maven2 свойство, которое указывает родительский каталог

94

У меня есть многомодульный проект, как этот:

main-project/
    module1/
    module2/
        sub-module1/
        sub-module2/
        sub-module3/
        ...
    module3/
    module4/
    ...

Мне нужно определить набор свойств (которые зависят от среды, в которой я хочу выпустить свой проект) в Maven2. Я не буду использовать<properties> так как есть много свойств ... Таким образом, я используюСвойства Maven2 плагин.

Файлы свойств расположены вmain-project/ каталог. Как я могу установить правильный каталог в основном файле pom.xml, чтобы указать дочерним элементам, где искать файл свойств?

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-1</version>
    <executions>
        <execution>
            <phase>initialize</phase>
            <goals>
                <goal>read-project-properties</goal>
            </goals>
            <configuration>
                <files>
                    <file>???/env_${env}.properties</file>
                </files>
            </configuration>
        </execution>
    </executions>
</plugin>

Если я установил только<file>env_${env}.properties</file>то, когда Maven2 скомпилирует первый модуль, он не найдетmain-project/env_dev.properties файл. Если я установлю<file>../env_${env}.properties</file>, тогда будет возникать ошибка на родительском уровне или на любом уровне субмодуля ...

Ваш Ответ

18   ответов
1

да нет Дляsub-module1, он укажет на каталогmodule2, неmain-project. Romain Linsolas
2
<plugins>
  <plugin>
    <groupId>org.codehaus.groovy.maven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.0</version>
    <executions>
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>execute</goal>
        </goals>
        <configuration>
          <source>
            import java.io.File
            project.properties.parentdir = "${pom.basedir}"
            while (new File(new File(project.properties.parentdir).parent, 'pom.xml').exists()) {
                project.properties.parentdir = new File(project.properties.parentdir).parent
            }
          </source>
        </configuration>
      </execution>
    </executions>
  </plugin>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-2</version>
    <executions>
      <execution>
        <phase>initialize</phase>
        <goals>
          <goal>read-project-properties</goal>
        </goals>
        <configuration>
          <files>
            <file>${parentdir}/build.properties</file>
          </files>
        </configuration>
      </execution>
    </executions>
  </plugin>
  ...
3

использовать $ {parent.relativePath}

<parent>
    <artifactId>xxx</artifactId>
    <groupId>xxx</groupId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>..</relativePath>
</parent>
<build>
    <filters>
        <filter>${parent.relativePath}/src/main/filters/filter-${env}.properties</filter>
    </filters>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>
Это не всегда может быть безопасно; $ {parent.relativePath} может содержать имя файла, например, & Quot; ../ pom.xml & Quot;
144

чтобы найти основной каталог проекта.

В родительском:

<properties>
    <main.basedir>${project.basedir}</main.basedir>
</properties>

У детей:

<properties>
    <main.basedir>${project.parent.basedir}</main.basedir>
</properties>

У внуков

<properties>
    <main.basedir>${project.parent.parent.basedir}</main.basedir>
</properties>
Как и Джонатан выше, я должен использовать относительные пути, но чувствую, что лучше всего использоватьfile.separator переменная, как это<main.basedir>${project.basedir}${file.separator}..</main.basedir>
Вздох. Невероятно, что Maven делает это так сложно.
У меня был успех с${project.basedir}/.. но это действительно работает только в многомодульных проектах, которые находятся в строгой иерархии каталогов.
Были ли удалены эти предварительно установленные свойства?${parent.basedir} больше не разбирает что-либо в 3.0.4 ...
Да, это не работает. $ {project.parent.basedir} оценивается как ноль.
-1

овательское свойство задается со свойством maven-default в POM верхнего уровня (в данном случае<parent.base.directory>${project.parent.basedir}</parent.base.directory>) будет установлен при прохождении по дереву. Другими словами,${parent.base.directory} будет правильно настроен в другом дочернем POM.

Обратите внимание, вы не должны использовать${parent.basedir} как пользовательское свойство, потому что оно совпадает с maven-default${project.parent.basedir} имущество. В противном случае он попадает в рекурсивную ошибку выражения в maven. Вот почему я использую${parent.base.directory} в ответ.

Надеюсь, что это коренное решение проблемы.

13

каталог-maven-плагин с каталогом-цели.

В отличие от других предложений:

This solution works for multi-module projects. It works whether you build the whole project or a sub-module. It works whether you run maven from the root folder or a sub-module. There's no need to set a relative path property in each and every sub-module!

Плагин позволяет вам установить свойство по вашему выбору для абсолютного пути любого из модулей проекта. В моем случае я установил его в корневой модуль ... В моем проекте root pom:

<plugin>
    <groupId>org.commonjava.maven.plugins</groupId>
    <artifactId>directory-maven-plugin</artifactId>
    <version>0.1</version>
    <executions>
        <execution>
            <id>directories</id>
            <goals>
                <goal>directory-of</goal>
            </goals>
            <phase>initialize</phase>
            <configuration>
                <property>myproject.basedir</property>
                <project>
                    <groupId>com.my.domain</groupId>
                    <artifactId>my-root-artifact</artifactId>
                </project>
            </configuration>
        </execution>
    </executions>
</plugin>

С этого момента $ {myproject.basedir} в любом подмодуле pom всегда имеет путь к корневому модулю проекта. И, конечно, вы можете установить свойство для любого модуля, а не только корень ...

Не ставьте «тест» для фазы. Вызвала у меня множество проблем. Прекрасно работает, как показано выше.
1

ответ на другой вопрос Я показал, как плагин maven-properties-plugin может быть расширен для использования дескрипторов внешних свойств, определенных в зависимостях Maven.

ы можете расширить эту идею, чтобы иметь несколько jar дескрипторов, каждый с именем среды как частью artifactId, содержащий $ {env} .properties. Затем вы можете использовать свойство, чтобы выбрать соответствующий файл jar и свойства, например:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-ext-maven-plugin</artifactId>
  <version>0.0.1</version>
  <executions>
    <execution>
      <id>read-properties</id>
      <phase>initialize</phase>
      <goals>
        <goal>read-project-properties</goal>
      </goals>
    </execution>
  </executions>                              
  <configuration>
    <filePaths>
      <!--assume the descriptor project has a file in the root of the jar -->
      <filePath>${env}.properties</filePath>
    </filePaths>
  </configuration> 
  <dependencies>
    <!-- reference the properties jar for the particular environment-->
    <dependency>
      <groupId>some.descriptor.group</groupId>
      <artifactId>env-${env}-descriptor</artifactId>
      <version>0.0.1</version>
    </dependency>
  </dependencies>
</plugin>
0

что если вы используете шаблон расширения, используемый в примере для плагина findbugs & amp; multimodule вы можете установить глобальные свойства, связанные с абсолютными путями. Он использует топ

пример для многомодульного

Pom верхнего уровня имеет несвязанный проект build-config и приложение-родитель для модулей многомодульного проекта. Приложение-родитель использует расширение, чтобы связать себя с проектом build-config и получить от него ресурсы. Это используется для переноса общих файлов конфигурации в модули. Это может быть проводником для свойств, а также. Вы можете записать верхний каталог в файл свойств, используемый конфигурацией сборки. (это кажется слишком сложным)

Проблема заключается в том, что для выполнения этой работы необходимо добавить новый верхний уровень в многомодульный проект. Я попытался отойти от действительно несвязанного проекта build-config, но он был грязным и казался хрупким.

0

размещенного в основном проекте многомодульного проекта. По сути, реальный путь был${basedir}/ Lib. Наконец я остановился на этом в моемparent.pom:

<repository>
    <id>local-maven-repo</id>
    <url>file:///${basedir}/${project.parent.relativePath}/lib</url>
</repository>

Тотbasedir всегда показывает текущий локальный модуль, нет способа получить путь к "master" проект (позор Maven). Некоторые из моих подмодулей находятся на одну глубину, некоторые на две глубже, но все ониdirect submodules родителя, который определяет URL репо.

Так что это не решает проблему в целом. Вы всегда можете объединить его с принятым ответом Клэя и определить какое-либо другое свойство - работает нормально и должно быть переопределено только для случаев, когда значение изparent.pom не достаточно хорош Или вы можете просто перенастроить плагин - что вы делаете только в POM-артефактах (родителях других подмодулей). Значение, извлеченное в свойство, вероятно, будет лучше, если оно понадобится в нескольких местах, особенно когда ничего в конфигурации плагина не меняется.

С помощьюbasedir в значении была существенная часть здесь, потому что URLfile://${project.parent.relativePath}/lib не хотел делать трюк (я удалил одну косую черту, чтобы сделать его относительным). Использовать свойство, которое дает мне хороший абсолютный путь, а затем идти относительно относительно него, было необходимо.

Когда путь не является URL / URI, это, вероятно, не такая проблема, чтобы отброситьbasedir.

1

чтобы записать свойство в корневой родительский файл свойств:

import java.io.*;
String p = project.properties['env-properties-file']
File f = new File(p)
if (f.exists()) {
try{
FileWriter fstream = new FileWriter(f.getAbsolutePath())
BufferedWriter out = new BufferedWriter(fstream)
String propToSet = f.getAbsolutePath().substring(0, f.getAbsolutePath().lastIndexOf(File.separator))
if (File.separator != "/") {
propToSet = propToSet.replace(File.separator,File.separator+File.separator+File.separator)
}
out.write("jacoco.agent = " + propToSet + "/lib/jacocoagent.jar")
out.close()
}catch (Exception e){
}
}
String ret = "../"
while (!f.exists()) {
f = new File(ret + p)
ret+= "../"
}
project.properties['env-properties-file-by-groovy'] = f.getAbsolutePath()
5

в родительском поме используйте:

<properties>
   <rootDir>${session.executionRootDirectory}</rootDir>
<properties>

В дочерних poms вы можете ссылаться на эту переменную.

Главное предостережение: оно заставляет вас всегда выполнять команду из основного родительского каталога pom. Затем, если вы хотите запускать команды (например, тестировать) только для определенного модуля, используйте этот синтаксис:

mvn test --projects

Конфигурация верного параметра для параметризации & quot; path_to_test_data & quot; переменная может тогда быть:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${surefire.plugin.version}</version>
    <configuration>
        <systemPropertyVariables>
            <path_to_test_data>${rootDir}/../testdata</path_to_test_data>
        </systemPropertyVariables>
    </configuration>
</plugin>
11

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

& Lt; & напыщенная GT;Я слышал, что об этом говорили как об анти-паттерне, но для каждого анти-паттерна существует реальный, законный вариант его использования, и мне надоело, что Мэйвен говорит, что я могу следовать только их паттернам. & lt; / rant & gt;

Так что работа вокруг, которую я нашел, заключалась в использовании antrun. Попробуйте это в дочернем pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.7</version>
    <executions>
        <execution>
            <id>getMainBaseDir</id>
            <phase>validate</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <exportAntProperties>true</exportAntProperties>
                <target>
                    <!--Adjust the location below to your directory structure -->
                    <property name="main.basedir" location="./.." />
                    <echo message="main.basedir=${main.basedir}"/>
                </target>
            </configuration>
        </execution>
    </executions>
</plugin>

Если вы бежитеmvn verify вы должны увидеть что-то вроде этого:

main:
     [echo] main.basedir=C:\src\parent.project.dir.name

Вы можете использовать${main.basedir} в любом из других плагинов и т. д. Мне потребовалось время, чтобы понять это, так что надеюсь, что это поможет кому-то еще.

как я могу передать его на maven-surefire-плагин?
6

...
<properties>
  <main_dir>${project.parent.relativePath}/..</main_dir>
</properties>
...

<plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0-alpha-1</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
            <configuration>
              <files>
                 <file>${main_dir}/maven_custom.properties</file>
              </files>
            </configuration>
          </execution>
        </executions>
</plugin>
3

проект C является подмодулем B, а B является подмодулем A. Вы пытаетесь связаться с модулем D 'ssrc/test/config/etc каталог из проекта C. D также является подмодулем A. Следующее выражение позволяет получить путь URI:

-Dparameter=file:/${basedir}/../../D/src/test/config/etc
14

я ищу файлы свойств с помощью плагина Groovy Maven.

Поскольку мой файл свойств обязательно находится в текущем каталоге, в ../ или в .. / .., я написал небольшой код Groovy, который проверяет эти три папки.

Вот выдержка из моего pom.xml:

<!-- Use Groovy to search the location of the properties file. -->
<plugin>
    <groupId>org.codehaus.groovy.maven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.0-rc-5</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    import java.io.File;
                    String p = project.properties['env-properties-file'];
                    File f = new File(p); 
                    if (!f.exists()) {
                        f = new File("../" + p);
                        if (!f.exists()) {
                            f = new File("../../" + p);
                        }
                    }
                    project.properties['env-properties-file-by-groovy'] = f.getAbsolutePath();
            </source>
            </configuration>
        </execution>
    </executions>
</plugin>
<!-- Now, I can load the properties file using the new 'env-properties-file-by-groovy' property. -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-1</version>
    <executions>
        <execution>
            <phase>initialize</phase>
            <goals>
                <goal>read-project-properties</goal>
            </goals>
            <configuration>
                <files>
                    <file>${env-properties-file-by-groovy}</file>
                </files>
            </configuration>
        </execution>
    </executions>
</plugin>

Это работает, но мне это не очень нравится.

Так что, если у вас есть лучшее решение, не стесняйтесь писать!

0

../../env_${env}.properties ?

Обычно мы делаем следующее, когда module2 находится на том же уровне, что и подмодули.

<modules>
    <module>../sub-module1</module>
    <module>../sub-module2</module>
    <module>../sub-module3</module>
</modules>

Я думаю, что ../ .. позволил бы вам подскочить на два уровня. Если нет, вы можете связаться с авторами плагина и посмотреть, является ли это известной проблемой.

Если я добавлю ../../env.props в основной файл pom.xml, я получу сообщение об ошибке, когда Maven2 попытается собрать основной модуль и весь модуль X. Эта конфигурация фактически работает только для всех подмодулей ... Romain Linsolas
6

фигурация для CheckStyle, которую я положил вconfig каталог в корне проекта, поэтому я могу запустить его из основного модуля и из подмодулей.

<profile>
    <id>root-dir</id>
    <activation>
        <file>
            <exists>${project.basedir}/../../config/checkstyle.xml</exists>
        </file>
    </activation>
    <properties>
        <project.config.path>${project.basedir}/../config</project.config.path>
    </properties>
</profile>

Он не будет работать для вложенных модулей, но я уверен, что его можно изменить для этого, используя несколько профилей с разнымиexists& APOS; с. (Я понятия не имею, почему в теге подтверждения должно быть "../..& quot;" и просто ".." в самом переопределенном свойстве, но оно работает только таким образом.)

Я не знаю, почему это работает (дополнительно ../), но это кажется самым чистым решением (у меня тоже были проблемы с конфигурацией checkstyle.xml)
0

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

<pluginManagement>
  <plugins>
    ..
    <plugin>
      <groupId>org.codehaus.gmaven</groupId>
      <artifactId>groovy-maven-plugin</artifactId>
      <version>2.0</version>
    </plugin>
    ..
  </plugins>
</pluginManagement>

Я решил не использовать свойство для определения имени файла. Обратите внимание, что если build.properties не найден, он будет вращаться вечно. Я добавил обнаружение .git dir, но не хотел слишком усложнять ответ, поэтому он здесь не показан.

  <plugin>
      <groupId>org.codehaus.gmaven</groupId>
      <artifactId>groovy-maven-plugin</artifactId>
      <executions>
          <execution>
              <phase>validate</phase>
              <goals>
                  <goal>execute</goal>
              </goals>
              <configuration>
                 <source>
                    import java.io.File;
                    String p = "build.properties";
                    while(true) {
                      File f = new File(p); 
                      if(f.exists()) {
                        project.properties['project-properties-file'] = f.getAbsolutePath();
                        break;
                      }
                      else {
                        p = "../${p}";
                      }
                    }
                </source>
              </configuration>
          </execution>
      </executions>
  </plugin>

Похожие вопросы