Spring Boot { batch + web } : quelle architecture du(des) projet(s) ?

Bonjour,

je n'arrive pas à trouver de réponse à la question qui suit, légèrement différente de celle-ci (https://www.developpez.net/forums/d1...ation-projets/).

La demande du client :
faire une appli qui offre à la fois :
- une partie WEB ou Rest (pour obtenir des écrans de CRUD qui pointent sur des tables Oracle)
- et plusieurs batchs (hebdos, mensuels)

Ma question :
est-ce possible en Spring Boot d'intégrer ces 2 composants { batch + web } ?
le cas échéant comment structurer le ou les projets et comment déployer ces composants ?
Sinon s'il faut faire en Spring "classique", quels points de vigilance et conseils auriez vous svp ?

Merci d'avance pour votre aide
Bonne journée

C'est tout à fait possible d'intégrer du web et des batchs dans Spring Boot.
Spring boot est grosso modo une couche haut niveau qui permet de générer des applications standalone (appli web, batchs, ...) et facilite aussi la gestion des dépendances.
Si je reprends l'exemple d'une application fournissant à la fois une appli web et des batchs, on aurait ce genre de structure Maven classique:

Code:

---

1 2 3 4 5 6

app-module-dao app-module-service app-module-web app-batchs pom.xml

---

Dans le pom racine de projet:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<project> <groupId>org.mycompany</groupId> <artifactId>myapp</artifactId> ... <modules> <module>app-module-dao</module> <module>app-module-service</module> <module>app-module-web</module> <module>app-module-batchs</module> </modules> </project>

---

La partie strictement spring-boot serait présente dans les pom dans les modules app-module-web et app-module-batchs
Le module app-module-web utilisera la dépendance spring-boot-starter-web et le module app-module-batchs spring-boot-starter-batch
Spring fournit un petit site web bien pratique https://start.spring.io/ qui génère une archive avec un fichier pom initialisé avec les bonnes dépendances spring.

Il faut juste garder à l'esprit que Spring Boot ne fait grosso modo que de l'encapsulation.
Dans le cas d'un module Web , spring boot génére un jar "fat" auto-exécutable (java -jar myapp.jar) qui embarquera l'appli web et ses dépendances avec son conteneur (Tomat, Jetty, ...).
Lancer l'appli web se résume à faire un java -jar myapp-web.jar ce qui lance le conteneur embarqué et l'appli web.
Dans le cas d'un module Batchs, spring boot génére un jar "fat" auto-exécutable (java -jar mybatchs.jar) qui embarquera le ou les batchs Spring (Couche Spring batch pour le traitement des gros volumes de données).

Pour répondre à la question sur le déploiement, cela dépend surtout des Ops du client.
Les Ops rechignent généralement à déployer une appli web comme un jar car ils n'ont pas la main sur la configuration/mise à jour/paramétrage du conteneur (Tomcat, Jetty, ...)

désolé pour le délai de réponse et un très GRAND merci NoClassDefFound pour tes explications très claires;

après coup j'avais cherché sur le net et ta solution me conforte dans la voie que j'ai suivie;
a priori j'avais pensé faire un pom parent qui contiendrait les dependances springboot communes; ça n'a pas marché comme je voulais;
alors finalement dans mon pom parent il n'y a que les modules comme tu le décris (et des properties comme l'encodage, utf8, le niveau de compil, java 8,...)
le pom de chacun des modules contient toutes les dependencies qui lui sont necessaires, indépendamment des autres modules (dommage c'est parfois redondant, notamment la version, mais je ne sais pas faire autrement)
comme la partie web a besoin du module service, j'ai donc ajouté au pom web la dependance a service

je ne connais pas encore le "fat" jar, ça m'a l'air très interessant;
provisoirement j'ai packagé mon web en war; je déploie avec le serveur embarqué ou avec un tomcat de base;
mais je me demande si ce que tu suggères (fat jar) ne serait pas plus adapté a l'infra de mon client qui deploie des images docker qui embarquent les applis, du coup si je laisse les ports standard (defaults de spring boot), les devops s'occuperont de faire les translations de port necessaires via la gestion docker (enfin je crois que c'est comme ça qu'ils font)