2014-11-11 2 views
1

У меня есть иерархия проекта, как:

A - pom.xml 
|__ B - pom.xml 
    |__ C - pom.xml 

Свойство project.version определено в pom.xml определено в А. Другие два pom указывают родительский тег и соответствующий относительный путь к соответствующему родительскому pom.

<parent> 
     <groupId>com.GRP.id</groupId> 
     <artifactId>ARTIFACT_ID</artifactId> 
     <version>${project.version}</version> 
     <relativePath>../pom.xml</relativePath> 
</parent> 

Проблема здесь в том, что специалист не в состоянии разрешить $ {project.version} и использует его как есть. Это бросает следующее исключение при выполнении из A/B/C:

[ERROR] The build could not read 1 project -> [Help 1] 
org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: 
[FATAL] Non-resolvable parent POM for com.project_name.module_name:sub_module_name:[unknown-version]: Could not transfer artifact com.project_name.module_name:module_name:pom:${project.version} from 
to env-module_name-all-repos (REPO_URL): Illegal character in path at index 96: https://DEMO 
/artifactory/env-module_name-all-repos/com/project_name/module_name/module_name/${project.version}/module_name-${project.version}.pom and 'parent.relativePath' points at wrong 
local POM @ com.project_name.module_name:sub_module_name:[unknown-version], C:\WorkSpaces\Repository\sub_module_name\pom.xml, line 10, column 10 

Любое предложение о том, как получить доступ к тем же от детей РОМ.

ответ

7

@Sumit,

Maven инспектирует <parent> блок и его содержимое groupId, artifactId и version перед проектом собственного groupId, artifactId и version.

Таким образом, вы должны избегать всего, что выглядит как ${...} внутри блока <parent>. Обратное положение в порядке, хотя: свойства родителя можно ссылаться в другом месте в файле пом:

<project> 

    <!-- parent's GAV: inspected first, cannot use tokens --> 
    <parent> 
     <groupId>com.GRP.id</groupId> 
     <artifactId>parent-id</artifactId> 
     <version>1.0-SNAPSHOT</version> 
    </parent> 

    <!-- project's GAV: inspected second, may reference parent --> 
    <groupId>${parent.groupId}</groupId> 
    <artifactId>child-id</artifactId> 
    <version>${parent.version}</version> 
    <properties> 
     <some.prop.name>${parent.artifactId}</some.prop.name>  <!-- parent-id --> 
     <some.other.prop>${project.artifactId}</some.other.prop> <!-- child-id --> 
    </properties> 
</project> 

думать об этом таким образом: если у вас есть сын или дочь, вы можете выбрать, чтобы назвать их после себя - но это не имеет смысла называть вы после вашего ребенка, так как вы появились сначала!

Надеюсь, что это поможет.

EDIT:

Давайте снова посмотрим на вашем примере ПОМ:

<parent> 
    <groupId>com.GRP.id</groupId> 
    <artifactId>ARTIFACT_ID</artifactId> 
    <version>${project.version}</version>  <!-- value doesn't exist yet --> 
    <relativePath>../pom.xml</relativePath> 
</parent> 

Таким образом, в файле pom.xml вашего ребенка, <parent> блок содержит ссылку на ${project.version}. Но, как упоминалось выше, это значение еще не существует, поскольку блок <parent> - это первое, что мы оцениваем.

Если вы измените его следующим образом, все будет в порядке:

<parent> 
    <groupId>com.GRP.id</groupId> 
    <artifactId>ARTIFACT_ID</artifactId> 

    <!-- EDIT 3A: parent.version is mandatory and must be a static value --> 
    <version>1.0-SNAPSHOT</version> 
    <relativePath>../pom.xml</relativePath> 
</parent> 
<groupId>com.GRP.id</groupId> 
<artifactId>CHILD_ARTIFACT_ID</artifactId> 

<!-- EDIT 3B: project.version is optional, can be deleted 
<version>${parent.version}</version> 
--> 

EDIT 2

Один последний бит информации.

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

Maven еще не знает, где находится файл pom.xml родителя.

Он должен использовать блок <parent>, чтобы выяснить, где находится файл pom, только после этого он может прочитать содержимое файла.

Надеюсь, что это прояснит ситуацию.

+0

Спасибо за ответ @ 333kenshin. Позвольте мне перефразировать мой вопрос. Поскольку вы упомянули, что родительский блок разрешен перед любым другим блоком в chiild pom.xml, поэтому почему maven не может разрешить '$ {parent.version}' в родительском блоке, так как это явно версия, упомянутая в parent pom.xml? – Sumit

+0

@Sumit: просмотрите мой ответ выше. – 333kenshin

+0

Спасибо 333kenshin. Еще один вопрос: есть ли какое-либо обходное решение, чтобы пропустить ' 1.0-SNAPSHOT' в родительском блоке child pom.xml. Наш огромный проект, поэтому очень сложно обновлять версию в каждом pom.xml каждый раз, когда выполняется новая версия. – Sumit

0

Maven позволяет использовать $ {project.version} в POM ребенка. Он просто ссылается на версию родителя, которую он может найти, ища родительский POM, который вы указываете, используя тег relativePath.

Вы случайно не используете Дженкинса? Если это так, это известная проблема в Дженкинсе. Взгляните на это: https://issues.jenkins-ci.org/browse/JENKINS-23846

Если нет, то какую версию Maven вы используете?

В отношении несвязанной стороны примечание по умолчанию для параметра relativePath является ../pom.xml, поэтому вам не нужно явно указывать, что (например, ваш образец POM), если вы выполните проект, следуя стандартной многомодульной структуре ,

0

Я хотел бы поделиться моей работой вокруг, я использую Maven 3.5.2

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

  2. Построить агрегат П или родитель П, который должен построить все дочерние модули

  3. Если у вас есть локальный репозиторий или хранилище нексуса раздвинуть изменения с обновленными версиями.

  4. Теперь все дочерние модули имеют фиксированную родительскую версию, которая была установлена ​​на шаге 1, мы можем использовать дочерние модули как зависимость от нескольких проектов.

Смежные вопросы