2011-09-22 14 views
6

Mam następujący scenariusz:projekt Maven z natywnym uzależnienia i kopiowanie plików

myLib jest biblioteką (dla których mam źródła, więc chciałbym, aby umieścić je w projekcie myLib Maven: myLib na przykład). Ta biblioteka ma zależność od słoika, dla której mam tylko słoik i nie można go znaleźć w repozytorium Maven (i NIE chcę go tam instalować). Aby go skompilować, coś takiego by działało: dodaj plik jar do projektu mylib w folderze "lib", np. "lib/thirdpartylib.jar" oraz w pliku pom.xml pliku mylib, dodaj zależność z samoczynnie wybraną grupą/artefaktem/wersją i wpisem "<scope>system</scope><systemPath>${project.basedir}/lib/thirdpartylib.jar</systemPath>". Projekt mylib skompiluje się dobrze.

Należy zauważyć, że mylib ma również zależność runtime od pliku dll, na przykład thirdparty.dll. Ale dla kompilacji nie jest to ważne.

Jednak co teraz zastanawiam się, jak osiągnąć następujące:

innych projektach, np Projekt "X", który wykorzystuje myLib będą potrzebne

- mylib.jar 
- thirdpartylib.jar 
- thirdpartylib.dll 

,

i będziesz musiał ustawić java.library.path do katalogu (np. "") w taki sposób, słoik i plik DLL trzeciej strony zostaną znalezione przez wirtualną maszynę wirtualną.

Moja troska jest taka: chciałbym, aby sonda/dll trzeciej strony była odpowiedzialna za projekt mylib. To znaczy. Chcę zdefiniować wiedzę, że musisz skopiować słoik i plik DLL trzeciej strony do folderu docelowego i że odnosi się do nich java.library.path, aby być częścią projektu mylib (mylib pom wie, jak to ma być stosowane w innych projektach). Jednak chcę, aby ta wiedza (tj. Instrukcje kopiowania, bez względu na to, jak dokładnie są wykonywane w Maven), była przekazywana do dowolnego innego projektu za pomocą mylib, na przykład X. Czy to jakoś możliwe?

[Moje rozwiązanie hack na razie byłoby to, że mam kopię rzeczy stron trzecich w X, ale nawet wtedy nie wiem jak skopiować/radzić sobie z plikiem DLL, więc musiałem napisać readme mówiąc, że plik dll musi zostać skopiowany do folderu bin uruchomionej maszyny wirtualnej).

Wszelkie sugestie są mile widziane!

Odpowiedz

2

Podstawa pomysł jest następujący:

  • Maven jest dobry w obsłudze za pomocą jednego wyniku Maven POM.
  • Możliwe jest posiadanie bibliotek i zależności dla tych bibliotek tylko w lokalnych repozytoriach.

Więc trzeba wykonać następujące czynności:

  1. Definiowanie dla dodatkowej biblioteki oddzielny projekt (lub modułu w projekcie) i zdefiniować bibliotekę jako wynik.
  2. Zmień POM, aby ten POM był teraz zależny od nowego projektu.
  3. Wykonaj te same kroki dla biblioteki DLL (zobacz wpis Managing DLL dependencies with Maven), jak to zrobić).
  4. Zainstaluj dodatkową bibliotekę i bibliotekę DLL w lokalnym repozytorium.

Teraz powinieneś być w stanie ponownie użyć Mavena do procesu kompilacji, a używając dodatkowych wtyczek, takich jak maven-assembly-plugin, możesz spakować wszystko razem.

13

Sugeruję obracając pliki do modułów Maven, instalując je w lokalnym repozytorium używając Maven install plug-in

mvn install:install-file \ 
    -DgroupId=com.demo \ 
    -DartifactId=thirdpartylib \ 
    -Dversion=1.0 \ 
    -Dfile=thirdpartylib.jar 

mvn install:install-file \ 
    -DgroupId=com.demo \ 
    -DartifactId=thirdpartylib-runtime \ 
    -Dversion=1.0 \ 
    -Dpackaging=dll 
    -Dfile=thirdpartylib.dll 

Jedną z najbardziej przydatnych rzeczy na temat tego podejścia jest to, że Maven POM zostanie wygenerowane automatycznie.

myLib projekt teraz deklaruje thirdparty moduły jako normalnych zależnościach w jego POM file:

<dependencies> 
    <dependency> 
     <groupId>com.demo</groupId> 
     <artifactId>thirdpartylib</artifactId> 
     <version>1.0</version> 
    </dependency> 
    <dependency> 
     <groupId>com.demo</groupId> 
     <artifactId>thirdpartylib-runtime</artifactId> 
     <version>1.0</version> 
     <scope>runtime</scope> 
    </dependency> 
</dependencies> 

Teraz gdy myLib moduł odwołuje pozostałych modułów (w zależności) z thirdparty moduły również pobierane jako zależności przechodnie.

+0

Trzymam się rozwiązania, dzięki człowieku. – mtrovo

Powiązane problemy