A qui s’adresse cet article

• aux développeurs J2EE,
• aux développeurs Java qui veulent essayer J2EE,
• aux chefs de projet qui veulent comprendre les difficultés rencontrées par leur équipe.

Cet article n’est pas un manuel d’apprentissage sur J2EE, d’Eclipse ou de Maven, mais plutôt une explication sur leur rôle dans le développement d’un projet de serveur Java.

De quoi parlerons-nous ?

Quand on veut développer une application serveur un peu sérieuse en Java, on se trouve aujourd’hui dirigé vers J2EE (Java Enterprise Edition). Sous cet acronyme simple et apparemment inoffensif, se cache une nébuleuse de techniques (EJB 2 / 3 / 3.1, JTA, servlets, JSP, JSF, …) sensées aider les architectes logiciels et les développeurs. Il est vrai qu’au prix d’une boulimie de lectures / formations / tentatives, on finit par trouver certaines qualités à J2EE. Comme vous l’aurez compris, je ne suis pas un fan pur et dur de cette technologie. Mais je n’ai pas grand chose d’équivalent à proposer.

Après avoir choisi d’utiliser J2EE,  il est nécessaire de sélectionner un programme Java qui va « héberger » notre application serveur. En apparence, on a plutôt le choix : GlassFish, Weblogic, WebSphere, Jonas, JBoss, Geronimo, …

En théorie, tous ces serveurs d’application se valent. C’est la magie promise par J2EE : grâce à une normalisation très détaillée (contenues dans des documents appelés  JSR publiés par Sun et maintenant Oracle), on espère se rapprocher d’un des Graals de l’informatique, pouvoir faire fonctionner un « programme » sur n’importe quelle plate forme (hardware, OS).

En pratique, c’est bien différent : chaque serveur – gratuit ou payant – implémente tout ou partie de la norme … Au fait, quelle version de la norme : J2EE 5 ou JEE 6 ? Certains serveurs implémentent partiellement une version. Dans cette jungle, un serveur devrait théoriquement se détacher du lot : GlassFish. En effet, d’après Sun Microsystems, garant de Java, ce serveur est l’implémentation de référence de la norme. Oui mais … depuis 2009, Sun a été racheté par Oracle et l’avenir de GlassFishV3 (certifié JEE 6, sorti en décembre 2009) est flou. A la fin de mars 2010, Oracle a publié une feuille de route pour les développements de Glassfish afin de convaincre les utilisateurs.

Sans doute pleinement rassurés par ces promesses, nous utiliserons donc GlassFish V3.

Maven

Pour nous, Apache Maven est un outil gratuit de la Fondation Apache qui permet de gérer tout le cycle de vie d’un projet Java :

• créer la structure de fichiers du projet,
• compiler les classes,
• gérer l’utilisation de librairies externes, notamment en les téléchargeant depuis des entrepôts (repositories),
• assembler tous les composants en un JAR, WAR ou EAR (c’est-à-dire une archive au format ZIP contenant des classes Java compilées, des pages JSP, des ressources – images, feuilles de styles, jars,  … – et enfin des fichiers XML de configuration)
• lancer l’exécution des tests et générer un rapport,
• déployer les composants sur un serveur si nécessaire.

Eclipse

Maven réalise beaucoup de travail pour nous, mais il ne nous aide pas à écrire du code (Java, JSP, HTML, CSS, …). Pour tout cela, nous avons besoin d’un outil et c’est là qu’intervient Eclipse. Cet outil gratuit contient toutes les fonctions d’édition que nous pouvons souhaiter : aide contextuel, aide à l’achèvement de mot (word completion), compilation / vérification en cours de frappe, … Eclipse gère aussi les projets Java. Et c’est là que commencent les questions ? Eclipse et Maven vont-ils se marcher dessus ? Voire se battre pour réaliser la même chose ? Le site du plugin Eclipse M2eclipse, qui permet l’utilisation de Maven dans Eclipse, fournit une explication sur l’intérêt de mélanger ces deux outils: Maven est un outil en ligne de commande qui permet de créer simplement tout le contexte d’un projet et son cycle de vie. Eclipse est l’outil graphique interactif pour faire les développement dans le projet.

On a assez travaillé pour l’instant

On fait un petit résumé pour terminer cette première partie. On a vu le rôle de JEE et des serveurs d’application, puis celui des outils Maven et Eclipse. Au final, pour pouvoir continuer, il nous faut donc maitriser :

• le langage Java,
• les spécifications JEE pour les serveurs,
• l’administration de GlassFish V3 (j’ai pudiquement passé sous silence l’utilisation d’une base de données – JavaDB par défaut – ),
• l’outil de gestion de projet Maven,
• l’environnement de développement intégré Eclipse.

Une paille !