Considérez l'exemple de superposition de l'application d'entreprise suivant:
Quelle serait la bonne approche pour l'organiser à Maven. Devrais-je créer un projet multicouille Maven? Si «Project-Services» est un module maven, peut-il être partagé avec les trois autres projets que chacun est une unité de déploiement indépendante?
Dans mes projets précédents, j'ai simplement créé 4 projets Maven différents et je n'ai jamais senti beaucoup besoin de rien d'autre.
Voulez-vous valider s'il existe une meilleure façon que ce que j'ai fait auparavant.
4 Réponses :
Vous pouvez réellement faire une approche. Si c'est vraiment un gros projet, vous souhaitez toujours construire et libérer en même temps qu'un projet multi-module est un bon ajustement. Vous le feriez comme ça probablement:
pom project (top level project that would define all of the modules) jar project (project-services) war project (project-web) war project (project-web-services) project-standalone (wasn't sure if this was a jar, or just some scripts, etc)
J'irais certainement avec un seul projet avec des modules pour vous assurer que les versions utilisées des bibliothèques de 3ème parties communes correspondent.
Avoir un projet POM-comme la racine et la mise en œuvre de toutes les artefacts et d'autres artefacts, il est généralement considéré comme une bonne pratique pour tout, mais des projets à un seul module.
Dans mon lieu de travail, nous avons de nombreux projets de haut niveau qui partagent des bibliothèques (15 projets de haut niveau partagent 35 bibliothèques). Nous sommes allés avec le projet unique par approche de bibliothèque. Aujourd'hui, quand nous devons les libérer tous en une fois, c'est un cauchemar.
Quelques problèmes auxquels nous sommes confrontés:
Si je devais tout recommencer (j'ai aidé à définir tout cela), j'utiliserais un seul projet multi-module. Si rien d'autre, tout libérant en un coup est un avantage énorme. Les projets pourraient ne pas être jolis dans Eclipse, mais ce n'est pas ce que vous devriez viser de toute façon.
L'inconvénient d'un projet énorme est que vous libérez souvent des artefacts qui n'avaient aucune modification. Je comprends la question de la libération, peut-être dans votre cas, vous modifiez réellement chaque artefact chaque fois que vous allez libérer ... auquel cas c'est moins tracas. Mais parfois, lorsque vous avez juste besoin de libérer un artefact, ne les libérez pas sans changement n'est inférieur à celui idéal.
Depuis que vous avez des dépendances directes entre les modules, je recommanderais également sur le projet multi-module.
Ce que je recommande souvent, c'est d'envisager le cycle de vie des modules. Par exemple: Si vous libérez le module de lot beaucoup plus souvent que la couche de service, cela pourrait être logique de la diviser. Donc, vous n'avez pas besoin de libérer des choses (déployer) sans changement. Puisque le lot n'est généralement pas déployé de la même manière que les fichiers .war. Mais cela dépend du cycle de vie des modules de service + par lots.
Dans la plupart des cas, le déménagement côte à côte. Donc +1 pour "un pour tous"