Od dłuższego czasu pracuję z następującymi narzędziami: Maven, Eclipse, Jetty. Nigdy nie starałem się na to by moje projekty dobrze współgrały z Eclipse ponieważ wszystko i tak uruchamiam przez Mavena. Korzyścią jest przenośność tego rozwiązania, wadą brak klikalnej wygody, tj zakładki serwerów w Eclipse i aplikacji które są na nich uruchomione.

Tuż przed nowym rokiem udało mi się skonfigurować Mavena i Eclipse oraz JRebel. Teraz po zmianie klasy czy konfiguracji Springa z poziomu Eclipse zmiany widać w Jetty uruchomionym z poziomu Mavena. Nie byłby to sukces sam w sobie gdyby nie fakt, że udało się to zrobić w z wieloma modułami. Oto przykład struktury projektu:

• domain – model danych oraz encje
• security – kod związany z zabezpieczeniami oraz ich konfiguracją
• dataaccess
  • api – interfejsy DAO oraz Fasad
  • jpa -dostęp do danych przy użyciu JPA
  • jdbc – dostęp dod anych z użyciem gołego JDBC
• web – końcówka webowa – kontrolery itp.
• distribution – tworzenie dystrybucji do środowiska testowego i produkcyjnego

Ogólnie strukturę tą można coraz bardziej rozdrabniać bądź zbijać tak by odpowiadała ona naszym potrzebom, w tym przypadku pominiemy dywagacje ponieważ nie o tym ten wpis ma być. Problemem przy tego typu strukturze jest to że zmiany w modułach dao są dostępne w module web dopiero po przebudowaniu obydwu, co czasami bywa uciążliwe. Rozwiązaniem byłoby użycie OSGi i serwera który to wspiera, po zmianie robili byśmy deploy bundle który się zmienił – było by to z pewnością wygodniejsze niż dwukrotny mvn install, jest jednak rozwiązanie jeszcze wygodniejsze – JRebel.

Konfiguracja Mavena

Jak już wspomniałem całość zmian nie wymaga nic od Eclipse ze względu na to, że całość deskryptorów jest generowana z poziomu Mavena przy pomocy maven-eclipse-plugin.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-eclipse-plugin</artifactId>
    <configuration>
        <buildOutputDirectory>target/classes</buildOutputDirectory>
        <projectNameTemplate>[groupId]_[artifactId]</projectNameTemplate>
    </configuration>
</plugin>

Drugi krok to stworzenie bądź modyfikacja zmiennej środowiskowej MAVEN_OPTS:

-noverify -javaagent:E:\tools\jrabel-2.2.1\jrebel.jar -Xdebug -Drebel.log.stdout=true -Drebel.log=true -Xrunjdwp:transport=dt_socket,server=y,address=4000,suspend=n -Xmx768m

Trzeci krok to konfiguracja JRebel. Oczywiście można skorzystać z javarebel-maven-plugin, ale mi nie udało się go poprawnie skonfigurować, dlatego też plik został stworzony ręcznie:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

    <classpath>
        <dir name="${basedir}/target/classes" />
        <dir name="${basedir}/../domain/target/classes" />
        <dir name="${basedir}/../security/domain/target/classes" />
        <dir name="${basedir}/../dataaccess/api/target/classes" />
        <dir name="${basedir}/../dataaccess/jpa/target/classes" />
        <dir name="${basedir}/../dataaccess/jdbc/target/classes" />
    </classpath>

    <war dir="${basedir}/webapp" /> <!-- lokalizacja plików JSP itp -->

    <web>
        <link target="/myapp"> <!-- nazwa kontekstu -->
            <dir name="${basedir}/webapp"> 
            </dir>
        </link>
    </web>

</application>

Dodatkowo należy wyłączyć przeładowania Jetty tak by nie kolidowały one z agentem JRebel. Całość w dalszym ciągu działa z poziomu Mavena i jest przenośne. Po tych wszystkich zmianach możemy się cieszyć trialem przez 30 dni bądź kupić licencję za jedyne 149$. :)