A compléter
Manque l'arborescence de test dans la capture d'écran développeur
Faire une première partie qui reprend l'arborescence des fichiers modules maven pom etc.
Du point de vue du développeur, une application est composée de plusieurs projets Eclipse, chaque projet correspondant à un module MAVEN.
Du point de vue de l'exploitant, une application est composée d'une hiérarchie unique de fichiers, issue de la décompression d'une archive WAR.
Sommaire :
Arborescence développeur
|
Le fonctionnement de MAVEN impose une architecture particulière : il n'y a que deux répertoires.
|
Arborescence exploitant
|
L'arborescence du produit déployé par l'exploitant est obtenue en décompressant un fichier WAR. Les chemins spécifiques à chaque type d'utilisateurs ont été décrits ci-dessus, nous allons maintenant voir les les arborescences communes. Les répertoires seront présentés avec des chemins relatifs. Les chemins sont à adapter en fonction du contexte de l'utilisateur : exploitant ou développeur. |
Le répertoire properties : les fichiers de configuration
Afin de centraliser la configuration une bonne pratique consiste à utiliser un fichier de configuration centralisant les paramètres de l'application. Ceci évite notamment de devoir modifier n fichiers différents.
Les paramètres seront définis dans le fichier default.properties et pourront être surchargés dans le fichier config.properties.
Les exploitants ont ainsi un seul fichier de configuration à gérer. Et la gestion des fichiers de propriétés décrits ci-dessous est alors à la charge du développeur.
Dans le cas où la configuration n'est pas centralisée, les fichiers de configuration sont en général fournis sous forme de fichiers d'exemple (xxx-example.xml).
Les exploitants peuvent renommer ces fichiers (en xxx.xml), mais les développeurs doivent copier les fichiers d'exemple sous leur nom final (en laissant les fichiers d'exemple en place car ceux-ci sont liés au dépôt SVN).
Tous les fichiers de configuration Spring utilisés par l'application sont déclarés dans le fichier applicationContext.xml.
properties/auth : l'authentification
Le fichier de configuration Spring auth-example.xml définit le bean authenticationService, qui sert à l'application à récupérer l'identifiant de l'utilisateur connecté. Il doit être copié en auth.xml.
properties/cache : le cache
Le fichier de configuration Spring cache-example.xml définit le bean cacheManager, qui sert à l'application à s'appuyer sur un gestionnaire de cache. Il doit être copié en cache.xml.
Le fichier de configuration EhCache ehcache-example.xml définit la configuration de la bibliothèque EhCache.
properties/dao : l'accès aux données
Le fichier de configuration Spring dao-example.xml définit la manière dont l'application récupère les données de la base de données, par exemple avec Hibernate.
Il doit être copié en dao.xml.
Le fichier de configuration Hibernate hibernate/hibernate.cfg-example.xml définit la manière dont Hibernate se connecte à la base de données. Il doit être copié en hibernate.cfg.xml. Il est référencé par le bean abstractHibernateSessionFactory défini dans le dao.xml.
Les fichiers de configuration Hibernate hibernate/mapping/.hbm* décrivent le mappingentre les classes Java et les tables de la base de données. Ils sont également référencés par le bean abstractHibernateSessionFactory de dao.xml. Il n'est en général pas nécessaire pour les administrateurs de modifier ces fichiers, ils ne sont pas fournis sous forme d'exemples.
properties/deepLinking : la gestion des liens
Le fichier de configuration Spring deepLinking-example.xml définit le bean deepLinkingRedirector, qui indique comment l'application gère les liens (hypertextes) directs. Il doit être copié en deepLinking.xml.
Le fichier de configuration Spring urlGeneration-example.xml définit le bean urlGenerator, qui génère les liens hypertextes vers l'application (avec prise en compte de l'authentification, des paramètres de liens directs, ...). Il doit être copié en urlGeneration.xml.
properties/exceptionHandling : la gestion des exceptions
Le fichier de configuration Spring exceptionHandling-example.xml définit le bean exceptionServiceFactory, qui indique comment l'application gère les exceptions. Il doit être copié en exceptionHandling.xml.
properties/i18n : la gestion de l'internationalisation
Le fichier de configuration Spring i18n-example.xml définit le bean i18nService, qui indique comment l'application récupère les chaînes de caractères utilisées dans l'application. Il doit être copié en i18n.xml. Les fichiers bundles/_.properties contiennent les chaînes de caractères proprement dites.
properties/init : l'initialisation et la mise à jour
Le fichier de configuration Spring init-example.xml définit le bean versionningService, qui indique la manière dont est initialisée la base de données. On y trouvera par exemple l'uid du premier administrateur de l'application qui sera créé automatiquement en même temps que la base de données. Il doit être copié en init.xml.
properties/ldap : l'accès à l'annuaire LDAP
Le fichier de configuration Spring ldap-example.xml définit le bean ldapService, qui indique comment sont faits les accès à l'annuaire LDAP. Il doit être copié en ldap.xml.
properties/log4j.properties : les traces de l'application
Le fichier log4j-example.properties configure log4j (la bibliothèque utilisée pour les traces).
properties/misc : des choses qu'on a pas su mettre autre part 
Le fichier de configuration Spring application.xml définit le bean applicationService, qui indique à l'application son numéro de version, copyright, ... Ce fichier n'est pas fourni sous forme d'exemple, il ne doit normalement pas être modifié par les exploitants.
Le fichier de configuration Spring abstractBeans.xml définit des beansabstraits utilisés par héritage (notamment dans * /src/main/resources/properties/web/controllers.xml*). Ce fichier n'est pas fourni sous forme d'exemple, il ne doit normalement pas être modifié par les exploitants.
properties/smtp : l'envoi de courriers électroniques
Le fichier de configuration Spring smtp-example.xml définit le bean smtpService, qui indique à l'application comment envoyer les courriers électroniques. Il doit être copié en smtp.xml.
properties/web : l'interface utilisateur
Le fichier de configuration Spring controlers.xml définit les contrôleurs de l'application, qui réagissent aux actions de l'utilisateur.
Le fichier de configuration Spring converters.xml définit les convertisseurs de l'application, qui convertissent des objets en chaînes (et inversement) lors des interactions utilisateur.
Le répertoire webapp : l'application web et ses bibliothèques
webapp/media : les fichiers statiques
On trouvera dans ce répertoire tous les fichiers délivrés de manière statique par l'application web aux clients :
- Les images,
- Les feuilles de style (*.css),
- Les scripts Javascript
- ...
L'intérêt de ce regroupement est de pouvoir shunter Tomcat par un frontal Apache, plus efficace pour le délivrement de ressources statiques.
/webapp/META-INF : le manifest
Le fichier /webapp/META-INF/MANIFEST.MF est produit automatiquement par MAVEN
/webapp/stylesheets : les pages JSF
Toutes les pages JSF doivent être situées à cet endroit pour pouvoir être protégées d'un accès direct de manière globale.
/webapp/WEB-INF : la configuration de l'application web
Le fichier portlet-example.xml indique à Pluto comment configurer la portlet, il n'est utilisé qu'en mode portlet. Il doit être copié en portlet.xml.
Les fichiers web-portlet-example.xml (resp. web-servlet-example.xml) est un exemple de configuration du contexte Tomcat associé à l'application. En mode portlet (resp. servlet), il doit être copié en web.xml.
/webapp/WEB-INF/jsf : les composants facelets
Tous les composants facelets utilisés dans le projet doivent se trouver dans ce répertoire.
/webapp/WEB-INF/lib : les bibliothèques de l'application
Même les applications en mode batch seulement doivent utiliser /webapp/WEB-INF/lib pour déposer leurs bibliothèques, même si dans ce cas le nommage n'est pas très approprié. C'est MAVEN qui se charge de créer et remplir ce répertoire.