Les artefacts pour Java EE et les profils Maven
La plateforme Java EE
1. Introduction à Java EE
Dans le premier chapitre de ce livre, Java SE est présenté lors de l’installation du JDK nécessaire au fonctionnement d’Apache Maven. Java EE (Java Enterprise Edition) se fonde sur les bases de Java SE en étendant ses fonctionnalités pour proposer aux entreprises une architecture robuste, sécurisée et rapidement exploitable pour les applications Java orientées vers les architectures web.
Java Enterprise Edition construit ainsi son architecture sur un ensemble d’API qui permettent de gérer des composants de natures variées : applications web, applications clientes, services web, etc. et d’assurer leur fonctionnement optimal grâce aux conteneurs Java EE des serveurs d’applications.
Le nom officiel donné à la plateforme Java Enterprise a été simplifié, passant de Java 2 Enterprise Edition (J2EE) à Java Enterprise Edition (Java EE) pour les versions supérieures ou égales à la version 5.0.
a. Historique de Java EE
Les premières spécifications pour la plateforme Java EE (à l’époque appelée J2EE) sont apparues en 1999, l’objectif de Sun Microsystems à l’époque étant de faire prendre le virage du développement d’applications orientés vers l’Internet à sa plateforme Java.
Les spécifications de la plateforme incluent :
-
Des modèles de composants pour développer des applications, ces composants ayant chacun une responsabilité bien définie dans le fonctionnement de l’application.
-
Une spécification technique permettant aux éditeurs de logiciels de proposer des serveurs d’applications pour héberger ces applications.
De nombreuses évolutions de cette plateforme vont ensuite apparaître au fur et à mesure du temps et des évolutions technologiques du langage Java et de la plateforme standard Java SE.
Les spécifications Java EE 5 ont été officialisées fin 2006. C’est une évolution majeure, notamment avec la refonte de l’API de développement des services web (JAX-WS).
Les spécifications pour la plateforme Java EE 6 ont été officiellement validées à la fin de l’année...
Les profils Apache Maven
1. Présentation générale
Évoqués à plusieurs reprises dans les premiers chapitres, les profils sont, ici, présentés afin de comprendre pourquoi ils sont indispensables sur les projets Apache Maven professionnels.
Le principe de base est le suivant : un profil est un sous-modèle du modèle de données du POM qui peut être déclaré dans le fichier settings.xml ou dans le POM du projet. Ainsi, tous les éléments qu’il met à disposition ont déjà été, pour la plupart, expliqués ou mis en application précédemment dans ce livre.
Les possibilités apportées par cette notion sont alors les suivantes :
-
Définir des valeurs pour des éléments non déclarés dans les fichiers XML.
-
Agrémenter le descripteur d’éléments déjà présents dans les fichiers XML.
-
Surcharger les valeurs des éléments déjà définis dans les fichiers XML.
a. Pourquoi utiliser les profils ?
Contrairement aux autres éléments du POM, les éléments compris dans les profils ne vont pas être obligatoirement pris en compte lors de l’exécution d’une commande Apache Maven sur un projet. Tout l’intérêt réside dans cette possibilité que possède le profil de faire partie ou non du processus selon des conditions qu’il définit lui-même.
Ainsi, cette notion donne la capacité d’adapter les éléments du projet selon la plateforme de destination cible (développement, tests d’intégration, recette, pré-production, production), selon le type et la configuration du système d’exploitation (Linux, Windows, version de Java) ou alors selon les contraintes spécifiques liées au traitement du projet.
Des exemples de mise en œuvre des profils sont présentés dans la suite de ce chapitre et tout au long des chapitres suivants.
Que ce soit dans les types de fichiers settings.xml ou pom.xml, l’élément <profile> destiné à déclarer un profil possède les éléments standard suivants :
<project> ou <settings>
...
<profiles> ...
Les types d’artefacts pour les projets Apache Maven
1. Les types d’artefacts par défaut
Chaque projet Apache Maven doit préciser le format de l’artefact qu’il va générer en sortie. Le type d’artefacts par défaut, si l’élément <packaging/> n’est pas présent, est le JAR. Comme il a été expliqué dans les chapitres précédents, chaque définition de packaging est liée à une implémentation du cycle de vie par défaut.
Ainsi, par défaut, Apache Maven propose la liste suivante de formats pour les artefacts :
-
pom (Project Object Model)
-
jar (Java ARchive) : maven-jar-plugin
-
ejb / ejb3 (Enterprise Java Bean) : maven-ejb-plugin / maven-ejb3-plugin
-
maven-plugin (pour la création de plugins Apache Maven)
-
ear (Enterprise ARchive) : maven-ear-plugin
-
war (Web application ARchive) : maven-war-plugin
-
rar (Resources Adapter aRchive) : maven-rar-plugin
-
par (Parity ARchive) : maven-par-plugin.
Chacun de ces formats redéfinit le cycle de vie pour adapter, dans la majorité des cas (excepté le pom), au minimum la phase package en y associant un goal spécifique de son plugin dédié.
Les formats WAR et EAR sont étudiés plus précisément et illustrés par des exemples dans la suite du chapitre. Tous les plugins internes à l’ASF possèdent un site web dédié où sont documentées les fonctionnalités offertes par chaque MOJO dans le cycle de vie et la configuration nécessaire à leur mise en œuvre.
2. Les archives pour les applications web (WAR)
a. Présentation
Le WAR (Web application ARchive) est un format de fichier créé pour distribuer en plus des classes Java déjà présentes dans le format JAR des fichiers de type dynamique (JSP, JSF) ou statique (HTML, XML, CSS...) liés au Web.
Ce format est un dérivé du JAR, comme en témoigne son type MIME : application/java-archive. Il s’en différencie de par son arborescence de fichiers et son chargement des classes qui est effectué à partir des emplacements WEB-INF/classes et WEB-INF/lib.
b. Apache Maven et le format WAR
Le format WAR est géré par le plugin de l’ASF...
En résumé
La mise en œuvre des plugins standards Maven montre l’étendue des possibilités qu’offre Apache Maven aujourd’hui pour des projets Java en règle générale et Java EE en particulier.
La force d’Apache Maven est sa capacité à répondre aux besoins de la communauté sur les projets Java. En effet, le plugin maven-shade-plugin a été créé pour faciliter un processus très utilisé avec le plugin maven-assembly-plugin mais dont la configuration à mettre en place était trop conséquente.
La combinaison de ces plugins et l’utilisation à bon escient des profils Apache Maven permet de répondre à une multitude de problématiques toujours présentes sur les projets d’entreprises.