Maven nie rozpoznaje modułów rodzeństwa podczas uruchamiania zależności mvn: drzewo

Question

Próbuję skonfigurować wielomodułowy projekt Maven, a zależności między modułami najwyraźniej nie są poprawnie skonfigurowane.

mam:

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

w POM macierzystego (który ma opakowanie typu POM) a następnie podkatalogów fotografia i/przechowywania /, które określają poms słoik z tej samej nazwie.

Przechowywanie zależy od Commons.

W głównym (master) katalogu, biegnę mvn zależność: drzewa i patrz:

[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 

Dlaczego zależność od „commons” fail, mimo że reaktor ma oczywiście widziałem go, ponieważ z powodzeniem przetwarza jego drzewo zależności? To na pewno nie należy chodzić do „siatki, żeby go znaleźć, ponieważ właśnie tam ...

POM do przechowywania:

<?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> 

Dzięki za wszelkie sugestie!

(Edit)

Aby wyjaśnić, co szukam tutaj jest taka: nie chcę mieć do zainstalowania modułu X zbudować moduł Y, która zależy od X, biorąc pod uwagę, że oba moduły są przywoływane z ten sam rodzic POM. W ten sposób intuicyjnie rozumiem, że jeśli mam dwie rzeczy w tym samym drzewie źródłowym, nie powinienem instalować produktów pośrednich, aby kontynuować kompilację. Mam nadzieję, że moje myślenie ma sens tutaj ...

Answer 1

Myślę, że problem polega na tym, że kiedy określasz zależność, Maven spodziewa się, że będzie to słoik (lub coś w tym rodzaju) zapakowany i dostępny od co najmniej lokalnego repozytorium. Jestem pewien, że jeśli uruchomisz mvn install na swoim wspólnym projekcie, wszystko będzie działać.

Answer 2

Jak omówiono w artykule this maven mailing list thread, zależność: cel drzewa samo w sobie będzie wyglądał lepiej w repozytorium niż w reaktorze. Można to obejść przez mvn instalowanie, jak wcześniej sugerowano, albo robi coś mniej uciążliwy, który wywołuje reaktor, taki jak

mvn compile dependency:tree 

pracuje dla mnie.

Answer 3

Uświadamiając sobie, że jest to starszy wątek, ale wydaje się, że narzędzie ewoluowało lub mogło zostać pominięte za pierwszym razem.

Możliwe jest wykonanie kompilacji, która sprawia, że ​​zależności są rozwiązywane bez instalowania przez wykonanie kompilacji reaktora.

Po uruchomieniu kompilacji w obiekcie nadrzędnym opisującym strukturę modułu projektu, zależności między modułami zostaną rozwiązane podczas samej instalacji przez wewnętrzny reaktor Maven.

Oczywiście nie jest to idealne rozwiązanie, ponieważ nie rozwiązuje problemu budowy pojedynczego modułu w strukturze. W tym przypadku Maven nie będzie miał zależności w swoim reaktorze i będzie szukał rozwiązania w repozytorium. Więc w przypadku pojedynczych kompilacji musisz najpierw zainstalować zależności.

Oto niektóre z opisów tej sytuacji: reference.

Answer 4

dla mnie, co doprowadziło mnie do tego wątku był podobny problem, a rozwiązanie było zapewnienie wszystkie pom zależnościami moduł miał

<packaging>pom</packaging> 

jednostka dominująca

pom

moim modelu dep miał pom - więc nie można było znaleźć słoja.

Answer 5

Jedyną rzeczą, która workd dla mnie: przejście do Gradle :(

mam

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

i mogę tylko cd w wojnę1 i użyć mvn tomcat7. Run-war zawsze mam aby przed zainstalowaniem cały projekt, mimo wojnę1 odwołuje jego rodziców i wojnę1 referencje rodzica i dep1 (jako moduły), więc wszystkie zależności powinny być znane.

nie rozumiem w czym jest problem.

Answer 6

Upewnij się, że moduł, który nie może zostać rozwiązany, wskazuje na prawą stronę nadrzędną, dołączając konfiguracje do pliku pom modułu.