Comment modularisation un (grand) Java App?

Question

J'ai une application assez large (plusieurs NMC) à portée de main que je voudrais diviser en plusieurs parties plus maintenable. Actuellement, le produit est composé d'environ 40 projets Eclipse, beaucoup d'entre eux ayant inter-dépendances. Ce seul fait un système de construction continue infaisable, car il faudrait reconstruire très bien à chaque checkin.

Y at-il une « meilleure pratique » façon de savoir comment

• identifier les parties qui peuvent être séparées immédiatement
• documents inter-dépendances visuellement
• dénouer le code existant;
• poignée « patches » nous avons besoin d'appliquer aux bibliothèques (actuellement traitées en les mettant dans la classpath avant que la bibliothèque réelle)

S'il existe des outils (libre / open) pour soutenir, je vous en serais reconnaissant des pointeurs.

Même si je n'ai aucune expérience avec Maven il semble que cela force un design très modulaire. Je me demande maintenant si c'est quelque chose qui peut être installé ultérieurement itérativement ou si un projet qui devait l'utiliser devrait être layouted avec modularité à l'esprit dès le départ.

Modifier 2009-07-10

Nous sommes dans le processus de séparation sur certains des modules de base en utilisant Apache Ant / Ivy . Vraiment utile et bien conçu outil, ne pas imposer autant sur vous maven fait.

J'ai écrit quelques détails généraux et opinion personnelle au sujet de pourquoi nous faisons cela sur mon blog - trop longtemps pour poster ici et peut-être pas intéressant à tout le monde, donc suivre à votre propre discrétion: www.danielschneller.com

Answer 1

Utilisation OSGi pourrait être un bon moyen pour vous. Il permettrait de créer des modules de l'application. Vous pouvez également organiser des dépendances d'une meilleure façon. Si vous définissez vos interfaces entre les différents modules correctement, vous pouvez utiliser l'intégration continue comme vous suffit de reconstruire le module qui vous affecté lors de l'enregistrement.

Les mécanismes fournis par OSGi vous aider à démêler le code existant. En raison de la façon dont le classloading fonctionne, il vous aide également à gérer les patches de manière plus aisée.

Certains concepts de OSGi qui semblent être un bon match pour vous, comme le montre de wikipedia:

Le cadre est divisé sur le plan conceptuel dans les domaines suivants:

• Bundles - Bundles sont des composants normaux pot avec des en-têtes supplémentaires manifestes
. li>
• Services d'enregistrement -. L'API pour les services de gestion (ServiceRegistration, ServiceTracker et ServiceReference)
• Cycle de Vie -. L'API pour la gestion du cycle de vie (installation, démarrage, arrêt, mise à jour et désinstaller des paquets)
• Modules -. La couche qui définit l'encapsulation et la déclaration des dépendances (comment un paquet peut importer et le code d'exportation)
• Sécurité -. La couche qui gère les aspects de la sécurité en limitant les fonctionnalités de paquet aux capacités pré-définies

Answer 2

D'abord: bonne chance et bon café. Vous aurez besoin à la fois.

J'ai déjà eu un problème similaire. Code Legacy avec dépendances circulaires terribles, même entre les classes de différents paquets comme org.example.pkg1.A dépend org.example.pk2.B et vice versa.

J'ai commencé avec maven2 et projets Eclipse frais. Tout d'abord j'ai essayé d'identifier les fonctionnalités les plus courantes (couche d'enregistrement, interfaces communes, services communs) et créé des projets Maven. Chaque fois que je suis heureux d'une part, je déployé la bibliothèque au référentiel central nexus de sorte qu'il était presque immédiatement disponible pour d'autres projets.

Je travaille lentement à travers les couches. maven2 manipulé les dépendances et le plugin m2eclipse fourni une vue en dépendance utile. BTW - il est généralement pas trop difficile de convertir un projet d'éclipse dans un projet Maven. m2eclipse peut le faire pour vous et il vous suffit de créer quelques nouveaux dossiers (comme src / main / java), et régler le chemin de compilation pour les dossiers source. Prend une minute ou deux. Mais attendez plus de difficultés si votre projet est un plugin Eclipse ou de l'application rcp et que vous voulez maven non seulement de gérer les artefacts, mais aussi pour construire et déployer l'application.

Pour avis, Eclipse, Maven et lien (ou tout autre gestionnaire de repository) sont une bonne base pour commencer. Vous avez de la chance, si vous avez une bonne documentation de l'architecture du système et cette architecture est vraiment mis en œuvre;)

Answer 3

J'ai eu une expérience similaire dans une petite base de code (40 Kloc). Il n'y a pas de règle ° ":

• compilé avec et sans "module" afin de voir son usage
• J'ai commencé de "modules de feuilles", des modules sans autres dépendances
• I manipulé dépendances cycliques (ce qui est une tâche très sujette aux erreurs)
• avec Maven il y a beaucoup de documentation (rapports) qui peuvent être déployés dans votre processus de CI
• avec Maven, vous pouvez toujours voir ce qui utilise ce aussi bien dans le site aussi bien dans NetBeans (avec un
  très agréable graphe orienté)
• avec Maven vous pouvez importer le code bibliothèque dans votre base de code, d'appliquer des correctifs source et compiler avec vos produits (il est parfois ce qui est très facile parfois très difficile)

Vérifiez aussi la dépendance Analyzer:
_{(source: javalobby.org )}

Netbeans:

_{(source: zimmer428.net )}

Answer 4

Maven est pénible de migrer vers un système existant. Cependant, il peut faire face à des projets de plus de 100 modules sans trop de difficulté.

Answer 5

La première chose que vous devez décider est ce que la structure infra-vous déplacer. Faut-il être un grand nombre de modules indépendamment maintenus (ce qui correspond à des projets individuels d'Eclipse) ou allez-vous considérer un seul morceau de code qui est versionné et déployé dans son ensemble. Le premier est bien adapté pour la migration vers un environnement de construction comme Maven -. Celui-ci pour avoir tout le code source à la fois

Dans tous les cas, vous aurez besoin d'un fonctionnement du système d'intégration continue. Votre première tâche est de rendre la construction de base de code automatiquement, donc vous pouvez laisser votre système de CI veille sur votre dépôt source et reconstruire whenyou changer les choses. J'ai décidé d'adopter une approche ici non Maven, et nous nous concentrons sur d'avoir un environnement Eclipse facile donc je créé un enviornment build en utilisant ant4eclipse et les fichiers ProjectSet équipe (que nous utilisons de toute façon).

L'étape suivante serait de se débarrasser des dépendances circulaires - cela rendra votre construction plus simple, se débarrasser des avertissements Eclipse, et éventuellement vous permettre d'obtenir à l'étape « checkout, compiler une fois, exécutez ». Cela peut prendre un certain temps :-( Lorsque vous migrez des méthodes et des classes, ne pas les déplacer, mais extraire ou les déléguer et de laisser leur ancien nom qui traînent et marquer déconseillés. Ce séparera votre untangeling avec votre refactoring, et permettre à un code " extérieur » votre projet fonctionne toujours avec le code dans votre projet.

Vous bénéficierez d'un référentiel source qui permet de déplacer des fichiers, et de garder l'histoire. CVS est très faible à cet égard.

Answer 6

Je ne recommanderais pas Maven pour une base de code source existant. Il pourrait vous donner beaucoup de maux de tête juste essayer d'adapter tout pour travailler avec elle.

Je suppose que ce que vous avez besoin est de faire un plan architectural de votre projet. Un outil peut aider, mais la partie la plus importante est d'organiser une vue logique des modules.

Answer 7

Il est pas libre, mais Structure101 vous donnera aussi bon que vous obtiendrez en termes d'outil soutien à frapper tous vos points de balle. Mais pour le disque que je suis partial, vous pouvez consulter SonarJ et Lattix aussi. ; -)