Projets d'amorçage Spring application.properties maven multi-module
Nous utilisons Spring Boot dans un projet multi-modules.
Nous avons un module d'accès au domaine qui a les classes d'objets de domaine commun, les référentiels, ainsi que la configuration pour la source de données, JPA, Hibernate, etc. Ceux-ci sont configurés à l'aide d'un application.properties. Nous avons mis toute cette configuration dans le module commun pour éviter la duplication de ces configurations communes dans les modules de niveau supérieur.
Tout cela fonctionne très bien lors de la construction du module de domaine, de sorte que les configurations sont correctement chargées dans les unités de test.
Cependant, les problèmes commencent lorsque nous essayons d'utiliser le module de domaine dans les modules de couche supérieure; ils ont leur propre application.properties, ce qui signifie que Spring les charge et non le module Domain application.properties, ce qui signifie que la source de données n'est pas configurée car seuls les modules application.properties supérieurs sont chargés.
Ce que nous aimerions, c'est que le module de domaine et les propriétés d'application de niveau supérieur soient chargés par Spring. Mais nous ne voyons aucun moyen facile de le faire.
Je pense que cela doit être un problème commun, et je me demande s'il existe des solutions recommandées pour ce problème?
Comme nous utilisons Spring-Boot, la solution devrait idéalement utiliser des annotations au lieu de applictionContext.xml.
Vous ne devriez peut-être utiliser que application.properties dans le projet d'agrégateur de niveau supérieur?
Vous pouvez toujours utiliser @PropertySource dans les projets enfants pour les configurer avec un nom spécifique à leur cas d'utilisation.
Ou vous pouvez utiliser des noms différents pour chaque projet et les coller ensemble dans le projet de niveau supérieur à l'aide de spring.config.location (séparées par des virgules).
Je suis d'accord avec @Dave Syer. L'idée de diviser une application en plusieurs modules est que chacun d'eux est une unité indépendante, dans ce cas un fichier jar. Théoriquement, vous pouvez diviser chacun de ces fichiers jar en leurs propres référentiels sources, puis les utiliser sur plusieurs projets. Supposons que vous souhaitiez réutiliser ces classes de domaine dans une application Web et par lots, si toute la configuration de niveau APPLICATION est stockée dans chacun des modules individuels, cela réduit considérablement leur réutilisabilité.
IMO seul le module d'agrégation doit contenir toute la configuration nécessaire pour fonctionner en tant qu'application, tout le reste est simplement une dépendance qui peut être remixée et réutilisée si nécessaire.
Une autre approche pourrait être de définir des profils spécifiques pour chaque module et d'utiliser le fichier application.properties juste pour spécifier que les profils de sorcière sont actifs en utilisant la propriété spring.profiles.include .
domain-module
- application.properties
- application-domain.properties
app-module
- application.properties
- application-app.properties
et dans le fichier application.properties du module d'application
spring.profiles.include=domain,app
Une autre chose que vous pouvez faire (en plus d'utiliser uniquement application.properties au niveau supérieur comme le mentionne Dave Syer) est de nommer le fichier de propriétés du module de domaine quelque chose comme domainConfig.properties.
De cette façon, vous évitez le conflit de noms avec application.properties.
domainConfig.properties contiendrait toutes les données nécessaires au module de domaine pour pouvoir le tester par lui-même. L'intégration avec le reste du code peut facilement se faire soit en utilisant plusieurs @PropertySource (un pour domainConfig.properties et un pour application.properties) ou en configurant un bean PropertySourcesPlaceholderConfigurer dans votre Java Config (consultez this tutoriel) qui fait référence à tous les fichiers de propriétés nécessaires