Piszę projekt do testów akceptacyjnych iz różnych powodów jest to zależne od innego projektu, który jest spakowany jako WOJNA. Udało mi się rozpakować WAR przy użyciu wtyczki maven-dependency-plugin, ale nie mogę zmusić mojego projektu do uwzględnienia rozpakowanego WEB-INF/lib/*.jari WEB-INF/classes/*umieszczenia w ścieżce klas, więc kompilacja się nie powiedzie. Czy istnieje sposób na dołączenie tych plików do ścieżki klas, czy też jest lepszy sposób polegania na WOJNIE?
Wielkie dzięki.
Odpowiedzi:
Istnieje inna opcja od maven-war-plugin 2.1-alpha-2. W Twoim projekcie WAR:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
Spowoduje to utworzenie artefaktu klas, którego można użyć w projekcie testów akceptacyjnych za pomocą:
<dependency>
<groupId>your-group-id</groupId>
<artifactId>your-artifact-id</artifactId>
<version>your-version</version>
<classifier>classes</classifier>
</dependency>
Rzeczywiście, zgodnie z projektem Maven nie rozwiązuje zależności przechodnich wojny zadeklarowanej jako zależność projektu. W rzeczywistości jest z tym problem, MNG-1991 , ale nie zostanie on rozwiązany w Maven 2.xi nie jestem pewien, czy nie wiem, czy nakładki pozwalają na obejście tego problemu. Moje rozumienie sugerowanego rozwiązania polega na powieleniu zależności, na przykład w projekcie typu pom.
(EDYCJA: Po kilku dalszych poszukiwaniach znalazłem coś interesującego w tym wątku, który cytuję poniżej:
Pomagałem w rozwoju projektu AppFuse przez ostatni miesiąc, w którym intensywnie wykorzystujemy funkcję nakładki wojennej we wtyczce wojennej Maven. To naprawdę fajna funkcja!
Aby uzyskać maksymalną moc dzięki nakładkom wojennym, opracowałem wtyczkę Warpath, która umożliwia projektom używanie artefaktów wojennych jako pełnoprawnych zależności. W skrócie:
1) Zawartość katalogu / WEB-INF / classes w artefaktach zależności wojny może zostać uwzględniona w ścieżce klas projektu dla normalnych zadań kompilacji itp.
2) Zależności przechodnie z artefaktów zależności wojennych stają się dostępne do użytku przez inne wtyczki, np. Compile i ear - więc nie trzeba już uwzględniać wszystkich zależności podczas tworzenia skinny war!Wtyczka jest teraz aktywnie używana w projekcie AppFuse przez ostatnie kilka miesięcy i czuję, że znajduje się w punkcie, w którym jest zarówno użyteczna, jak i stabilna. Czy zespół wtyczki wojennej byłby zainteresowany włączeniem funkcji Warpath do wtyczki wojennej? Wydawałoby się, że jest to najbardziej naturalne miejsce na jego organizację.
Nie mam z tym żadnego doświadczenia, ale wtyczka maven warpath faktycznie wygląda ładnie i prosto i jest dostępna w centralnym repozytorium. Aby z niej skorzystać, umieść w swoim pom.xmlpliku następujący element konfiguracyjny wtyczki :
[...]
<build>
<plugins>
<plugin>
<groupId>org.appfuse</groupId>
<artifactId>maven-warpath-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>add-classes</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
I dodaj zależności wojny, które chcesz uwzględnić w ścieżce klas jako zależności typu warpath :
[...]
<dependencies>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>warpath</type>
</dependency>
</dependencies>
[...]
Potrzebne są zarówno typy zależności wojny, jak i ścieżki wojny: typ wojny jest używany przez wtyczkę wojenną Maven do wykonania nakładki wojennej, typ ścieżki wojny jest używany przez wtyczkę Warpath do określenia prawidłowej listy artefaktów do włączenia do ścieżki klas projektu.
Spróbowałbym.)
Użyj nakładek . Po pierwsze, Twój projekt testowy musi mieć również opakowanie war.
Zadeklaruj zależność projektu wojennego, który chcesz przetestować:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>your-project-arftifactId</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>test</scope>
</dependency>
następnie skonfiguruj nakładkę maven-war-plugin:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/webresources</directory>
<filtering>true</filtering>
</resource>
</webResources>
<overlays>
<overlay/>
<overlay>
<groupId>your.group</groupId>
<artifactId>your-project-artifactId</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
W powyższym przykładzie w projekcie testowym nadpisuję pliki konfiguracyjne webresources (takie jak conxtext itp.).
EDYCJA: To rozwiązanie nie było testowane z Maven 3.
Słuszna uwaga, Justin. To sprawiło, że faktycznie rozwiązałem mój problem, a mianowicie: włączenie wojny do zespołu ORAZ włączenie wszystkich jego zależności przechodnich. Nie mogłem zduplikować zależności wojny jako „jar”, jak sugerowałeś, ponieważ wtyczka asemblera nie znalazłaby pliku jar, do którego odwołuje się ten groupId / artefactId, ale
Pracuje! Wojna i jej przechodnie zależności nie są zawarte w zestawie. Aby wykluczyć (teraz również pojawiający się) plik pom, musiałem dodać taki element wykluczający:
<excludes>
<exclude>*:pom</exclude>
</excludes>
do mojego pliku assembly.xml.
Myślę, że może to być również obejście pierwotnego pytania tego wątku.