Automatyczne inicjowanie tabel Quartz Schedulera

Próbując stworzyć ostatnio prosty projekt, a w zasadzie sam template - natknąłem się na kilka problemów.

Chciałem, aby FlyWay na start dla mojego projektu od razu tworzył wymagane przez Quartz Scheduler tabele, abym ja nie musiał podczas czyszczenia czy stawiania projektu od nowa wykonywać żmudnych czynności typu tworzenie tabel. Niestety spring-boot-starter-quartz tej czynności za nas nie zrobi (lub może ja przeoczyłem jakieś docs’y). W każdym razie lubię mięc kontrolę nad swoim środowiskiem i w łatwy sposób mieć możliwość postawić je na nowo, dlatego takie podstawowe inicjowanie projektu to dla mnie “must have”.

Potrzebowałem na start prosty projekt Spring, takowy więc wygenerowałem poprzez Spring Initializr.
Ostatecznie nie mogłem go uruchomić, aby spełniał poniższe warunki:

• Baza danych stawiana lokalnie na dockerze
• Spring 2.7.6
• Spring Boot Starter Quartz
• FlyWay

Niestety flyway odmawiał posłuszeństwa wypluwając mi poniższy błąd:

mvn clean install

[ERROR] Failed to execute goal org.flywaydb:flyway-maven-plugin:9.8.3:migrate (default) on project face-photo-manager: org.flywaydb.core.api.FlywayException: No database found to handle jdbc:mysql://localhost:3306/pubrom -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

W trakcie zdecydowałem się przerzucić z MySQL’a na MariaDB. W okolicach listopada 2022 przenoszone były biblioteki mvn i był to główny powód, który zniechęcił mnie do szukania driverów oraz bibliotek…

EDIT (2022-12-11): W dodatku podobny problem miałem podczas używania DBeaver’a kiedy w pewnym momencie w trakcie pracy w projekcie komercyjnym zaczęło mi wyskakiwać mnóstwo błędów (tutaj dodam, że DBeaver aktualizuje mi się przez snap’a - więc zazwyczaj taka aktualizacja jest opóźniona - a sam nie lubię się bawić w downgrade’y)

Co się zmieniło?

• mysql » mysql-connector-java

Został przeniesiony do:

• com.mysql » mysql-connector-j

Dla projektu wymagana była oczywiście podstawowa konfiguracja poniższego pluginu (lub zdefiniowanie tych samych właściwości w application.properties):

 <plugin>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-maven-plugin</artifactId>
    <version>9.8.3</version>
    <executions>
        <execution>
            <phase>generate-sources</phase>
            <goals>
                <goal>migrate</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <url>jdbc:mariadb://localhost:3306/project</url>
        <user>admin</user>
        <password>Root123!zxc</password>
        <baselineOnMigrate>true</baselineOnMigrate>
        <schemas>project</schemas>
        <locations>
            <location>
                filesystem:src/main/resources/db/migration
            </location>
        </locations>
    </configuration>
</plugin>

EDIT (2022-12-11): Osobiście przy moim małym niekomercyjnym projekcie zdecydowałem, że prościej jednak wykorzystywać properties, a samego pom.xml mieć czystszego bez nadmiaru wpakowanych pluginów, których w rzeczywistości i tak są mi zbędne. Więc poniższy plugin ostatecznie wyleciał z mojego pom’a.

Posiadałem w pom.xml podstawowe zależności:

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>
<dependency>
    <groupId>org.mariadb.jdbc</groupId>
    <artifactId>mariadb-java-client</artifactId>
</dependency>

Jednak rozwiązaniem okazał się brak w pom.xml dodatkowej zależności odnoszącej się do mysql:

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-mysql</artifactId>
</dependency>

EDIT (2022-12-11): Dodanie tej zależnosci wbrew pozorom nie jest wcale oczywiste przy używaniu MariaDB. Ciekawe swoją drogą czy jest on również wymagany przy korzystaniu z np. PostgreSQL - lub może trzeba dodać inną dedykowaną zależność pod innego typu bazę danych)

Poniżej umieszczam przydatne pliki konfiguracyjne, od których można startować tworząc nowy projekt:

GITHUB GIST: https://gist.github.com/Grala96/65e3d60b0984ca1656cffb0d84bbf2e0

• application.properties
• docker-compose.yml
• init-quartz-scheduler.sql
• pom.xml