Pergunta

Eu estou tentando configurar um projeto Maven multi-módulo, e as dependências entre os módulos são, aparentemente, não sendo configurado corretamente.

Eu tenho:

<modules>
  <module>commons</module>
  <module>storage</module>
</modules>

no POM principal (que tem um tipo de embalagem pom) e depois subdiretórios commons/ e storage/ que definem poms JAR com o mesmo nome.

Armazenamento depende Commons.

No diretório principal (master), eu corro mvn dependency:tree e veja:

[INFO] Building system
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] domain:system:pom:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
[INFO] Building commons
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
...correct tree...
[INFO] ------------------------------------------------------------------------
[INFO] Building storage
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
Downloading: http://my.repo/artifactory/repo/domain/commons/1.0-SNAPSHOT/commons-1.0-SNAPSHOT.jar
[INFO] Unable to find resource 'domain:commons:jar:1.0-SNAPSHOT' in repository my.repo (http://my.repo/artifactory/repo)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) domain:commons:jar:1.0-SNAPSHOT

Por que a dependência de "commons" falhar, mesmo que o reactor tem obviamente visto porque ele processa com êxito a sua árvore de dependência? Ele definitivamente não deve estar indo para o 'net para encontrá-lo como está à direita lá ...

O pom para armazenamento:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <packaging>jar</packaging>
  <parent>
    <artifactId>system</artifactId>
    <groupId>domain</groupId>
    <version>1.0-SNAPSHOT</version>
  </parent>
  <groupId>domain</groupId>
  <artifactId>storage</artifactId>
  <name>storage</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <!-- module dependencies -->
    <dependency>
      <groupId>domain</groupId>
      <artifactId>commons</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>

    <!-- other dependencies -->
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Obrigado por todas as sugestões!

(Edit)

Para esclarecer, o que eu estou procurando aqui é esta: eu não quero ter que instalar o módulo X ao módulo de construção Y que depende de X, uma vez que ambos são módulos referenciados a partir do mesmo POM pai. Isso faz sentido intuitivo para mim que se eu tiver duas coisas na mesma árvore fonte, eu não deveria ter que instalar produtos intermediários para continuar a construção. Espero que o meu pensamento faz algum sentido aqui ...

Foi útil?

Solução

Eu acho que o problema é que quando você especificar uma dependência Maven espera tê-lo como jar (ou qualquer outro) embalados e disponível a partir de pelo menos um repositório local. Tenho certeza que se você executar mvn install em seus commons projeto de trabalho primeiro de tudo vontade.

Outras dicas

Como discutido na esta discussão maven lista de tópicos , a dependência: meta árvore por si só vai olhar as coisas no repositório em vez do reator. Você pode contornar isso instalando mvn, como previamente sugerido, ou fazendo algo menos onerosa que invoca o reator, como

mvn compile dependency:tree

funciona para mim.

Percebendo esta é uma discussão mais velhos, mas parece que a ferramenta evoluiu ou isso pode ter sido perdido na primeira vez.

É possível executar uma compilação que faz dependências resolvidas sem instalar fazendo uma compilação reator.

Se você começar a sua construção no pai que descreve a estrutura do módulo de seu projeto, em seguida, suas dependências entre os módulos serão resolvidos durante a própria construção através do reator interno Maven.

É claro que esta não é a solução perfeita, pois não resolve a construção de um único módulo individual dentro da estrutura. Neste caso Maven não terá as dependências em seu reator e abelha procurando resolvê-lo no repositório. Então, para o indivíduo constrói você ainda tem que instalar as dependências primeiro.

Aqui estão algumas referência descrever esta situação.

para mim, o que me levou a esta discussão foi um problema semelhante e a solução foi para garantir que todos do pom módulo de dependência estiveste

 <packaging>pom</packaging>

o pai tinha

pom

meu modelo dep teve pom -. Por isso não havia frasco de ser encontrado

A única coisa que workd para mim: a mudança para Gradle: (

Eu tenho

Parent
  +---dep1
  +---war1 (using dep1)

e eu posso apenas cd em war1 e uso mvn tomcat7:-guerra executado. Eu sempre tenho que instalar todo o projeto antes, apesar das referências war1 seu pai eo pai referências war1 e dep1 (como módulos) para todas as dependências deve ser conhecido.

Eu não entendo qual é o problema.

Em uma estrutura de módulo Maven como esta:

- parent
  - child1
  - child2

Você terá no parent pom isto:

<modules>
  <module>child1</module>
  <module>child2</module>
</modules>

Se você agora dependem child1 em child2, colocando o seguinte no seu <dependencies> em child2:

<dependency>
  <groupId>example</groupId>
  <artifactId>child1</artifactId>
</dependency>

Você receberá um erro que o JAR para child1 não pode ser encontrado. Isso pode ser resolvido, declarando um bloco <dependencyManagement> incluindo child1 na pom para parent:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>example</groupId>
      <artifactId>child1</artifactId>
      <version>${project.version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>

child1 agora será construir quando você executa uma compile ou objetivo package etc. no parent e child2 vai encontrar arquivos compilados da child1.

Bonusing fora a resposta de Don Willis :

Se a sua construção cria-teste frascos para código de teste share entre seus submódulos reator você deve usar:

mvn test-compile dependency:tree

que permitirá dependency:tree para executar a conclusão neste caso.

Certifique-se o módulo que está falhando é resolvido no pom, está apontando para o pai direito, incluindo as configurações no arquivo pom do módulo.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top