Co to jest dobra struktura katalogów wdrażania dla aplikacji konsolowych java

Question

Mam aplikację konsoli Java, która jest gotowa do wdrożenia na serwerze Unix. Piszę skrypt powłoki, aby uruchomić aplikację.

Mam zamiar umieścić moje skrypty powłoki w jednym folderze, jar aplikacji i słoiki zależne (wiosna itp.) W innym folderze i plikach właściwości (te, które muszą być utrzymywane "na żywo") ponownie w oddzielnym folderze . Chciałbym wtedy, aby mój skrypt powłoki iterował przez pliki w folderach "jars" i "properties", dołączając je do ścieżki klasy, zanim w końcu wywołanie java ...

Czy jest to "dobra" struktura wdrażania? Czy istnieją jakieś wskazówki dotyczące rozmieszczania plików, aby zmaksymalizować łatwość konserwacji i stabilność? Czy istnieją oczywiste "złe" sposoby robienia tego, czego najlepiej unikać?

Powinienem dodać, że w przypadku poprzedniego projektu wszystkie skrypty powłoki (te, które uruchamiają procesy Java i te, które tego nie robią) umieszczam w folderze skryptów, mój jar aplikacji w folderze ze słojami biblioteki w bibliotece podfolder i zasoby zewnętrzne do podfolderu config. Następnie napisałem skrypt, który jawnie ładuje wszystkie pliki. Długo czekało na pisanie i musi być utrzymany za każdym razem, gdy aktualizuję słoik biblioteki. Tym razem chciałbym to zrobić lepiej. Ponadto nie ma potrzeby oddzielania pliku JAR aplikacji od bibliotek.

Answer 1

Za to, co jest warte, używamy tego;

/ 
    /class 
     //package hierarchy here, raw .class files 
    /lib 
     //library jars here, apache commons, gson etc, all .jars 
    /conf 
     //.properties files go here, including ones for libraries 
    /doc 
     //program documentation files, typically .txt 
     /javadocs 
      //java doc html root 
    /sh 
     //shell scripts including execute.sh and compile.sh 

Używamy ant na budowę, często mają src folder na drzewie źródłowym, jeśli to konieczne. W ten sposób dodajesz /class i /lib do swojej ścieżki klas, która nigdy się nie zmienia.

Answer 2

Dobra struktura dla twojego przypadku to tak zwany uberJar lub oneJar, który może być wykonany z wieloma narzędziami, po prostu google. Mogę też polecić taki fajny fragment kodu, jak http://www.jdotsoft.com/JarClassLoader.php

Answer 3

Szczerze mówiąc, jeśli jest to tylko niewielka aplikacja, umieściłbym wszystko pod /opt/<my_java_app> i posiadałbym podstrukturę katalogu tak jak w dev.

Jeśli chcesz być bardziej zgodny z UNIX zalecane praktyki, a następnie umieścić swój plik wykonywalny (w tym jar) w /usr/local/bin/<my_java_app>, plików konfiguracyjnych w /etc/<my_java_app>, pliki i inne pliki danych dziennika w /var/<my_java_app>.

Możesz również zapoznać się z this document.

Answer 4

Utwórz pakiet systemowy i użyj domyślnych ustawień systemowych. Jeśli używasz Debiana, utwórz plik .deb bezpośrednio z systemu kompilacji (na przykład używając ant deb task). Jeśli używasz rpms, użyj rpm task. W ten sposób możesz łatwo wdrożyć, odinstalować i zaktualizować aplikację, tak jak każdą inną.

Pakiet systemowy powinien oddzielić biblioteki (używam /usr/share/java/AppName dla moich słoików) i konfiguracji (do /etc/AppName lub /home/UserName/.AppName); skrypty uruchomieniowe, które są dowiązaniem symbolicznym do /usr/bin. Poza tym, nie ma wielkich komplikacji, aby wszystko działało. Polecam znajdowanie dobrze znanych pakietów opartych na javie w twojej dystrybucji i kopiowanie ich skryptów uruchamiania (w szczególności ich magii lokalizującej VM).