Pour moi l’usage d’une base embarquée est une vraie bonne pratique, d’ailleurs je ne fais plus que comme celà.

Il y a beaucoup à y gagner.

1. Facilité de mise en place et de fonctionnement en environnements réseaux différents : mes tests fonctionnements dans tous les cas. Que ce soit sur mon poste, connecté en mode réseau ou non. Que ce soit sous Eclipse, sous Maven. Que ce soit lancé depuis un serveur unix en tests d’intégration continue. Ca marche toujours pareil. Enorme facilité de mise en place également : une base embarquée se démarre facilement en Java, il n’y a rien à administrer, ce n’est pas du tout pareil avec un Oracle XE par ex. (ou avec une instance Oracle distante sur un autre serveur). Et avec une base embarquée on est sûr que chaque base n’est utilisée que ce pour quoi elle est prévue : ici faire tourner les tests (il n’y a pas plusieurs personnes mappées dessus, etc.).

2. Performances. Oui Oracle c’est bien en production (fiabilité en cas de crash, etc.), mais entre une base rapide embarquée locale et un serveur Oracle distant, çà n’a rien à voir niveau perfs (mes campagnes de tests sont 10x plus rapide sous HSQLDB par ex. que sous Oracle11G (sur un serveur déporté). Performances aussi en local, çà n’a rien à voir de faire tourner sur son poste une base de ce genre ou un Oracle XE. Et si on veut déployer N instances Oracle sur un serveur unix distant pour N développeurs, çà a aussi un coût de maintenance / installation / ressources plus important.

Au final je ne travaille plus que sur HSQLDB en local.
Mon canevas de test est simple : au début de test, on démarre la base HSQLDB en mode “mémoire” (rien n’est écrit sur le disque). Chaque test case met en place le schéma de la base et les données correspondantes (ou çà peut être mutualisé en test suite), afin de faire au maximum en sorte que chaque test soit indépendant les uns des autres (histoire de garantir qu’un test bdd seul fonctionne, et que n’importe quel enchaînement de tests bdd également), c’est une règle de base.

Concernant les deux points évoqués :
- oui le moteur est différent. Et alors ? Au moins çà me garantit que le code SQL que j’écris est standard et portable, ce qui est plutôt une bonne chose (pas de jointures écrites “à la mode Oracle” par ex. si on fait des DAO à la main, etc.). Par contre en effet il ne faut pas avoir besoin de faire appel à des fonction spécifiques de la base cible (mais ce n’est pas mon cas, pas de vues matérialisées et autres artifices qui rendent trop dépendants du SGBDR cible et qui peuvent bien souvent être évités).
- en cas de plantage sur les tests, à l’instant T, oui les données sont perdues, mais : a) le fait de pouvoir lancer n’importe quel test en autonome fait qu’il est facilement possible de rejouer le test concerné et b) il est tout à fait possible soit de mettre un point d’arrêt sur une exécution locale sous Eclipse pour voir ce qui se passe en base, soit d’avoir la base (ici HSQLDB) en mode “fichier”, qui restent donc en l’état en fin de tests et peuvent être réexploités (il suffit de redémarrer la base …).

Au final je ne reviendrai pas sur un mécanisme avec des tests sur une base Oracle externe : c’est beaucoup trop de contraintes, çà demande trop de ressources, çà pose trop souvent problèmes (base indisponible, base utilisée par plusieurs personnes car trop coûteux d’en avoir N séparées, temps de traitement bien plus longs, etc.).

Oui, mais pas spécialement implémenter des outils propriétaires. Glassfish implémente la jsr dont-j’ai-oublié-le-numéro qui permet de gérer n’importe quel serveur d’applications java, je trouve que maven peut l’utiliser directement. Je trouve l’incorporation d’outils propriétaires dangereuse et sans limite claire, d’autant qu’il n’y a à mon avis pas de nécessité à incorporer ça dans Glassfish, ça peut être extérieur.

Voir https://maven-glassfish-plugin.dev.java.net/ . Je pense qu’on peut maintenant faire tout ça de manière standard (ce n’est pas spécifique à Glassfish).

1. JCP est bien plus fermé qu’OSGI:
Tu ne rentre dans le comité exécutif du JCP que si tu es un grand industriel: “The EC represents both major stakeholders and a representative cross-section of the Java Community”.
Pour les grades de membre voici les tarifs: http://jcp.org/en/participation/membership

OSGI n’a pas de grade plus haut que “full member” et est ouvert sur paiement de la licence: http://www.osgi.org/About/Join
IBM est full-member. Donc si vous payer le prix, vous aurez autant de pouvoir de décision sur les specs.

2. OSGI se devrait plus d’être comparé à une JSR. OSGI est un ensemble de spécification pas un processus

3. “OSGI propose des fonctionnalités dont peu de monde a besoin. Par exemple, l’arrêt/relance de bundle à chaud”
Vous redémarrez votre serveur à chaque fois que vous déployer votre application ?
Vous n’avez jamais trouvé nécessaire de re livrer qu’une partie de votre application sans refaire tout un process de déploiement ?

4. “IBM a besoin de log4j, il va créer son bundle. Idem pour Eclipse”
Hummm… vous êtes sur ?

Par exemple, pour une meilleure lisibilité du code il est problématique d’avoir une table “T_ACHETEUR” dans la base de données, sa classe Java pour le mapping “P03_01_HumanBeingEntity” et une entitée JPA “buyer”.
Techniquement, c’est possible… mais lorsque le fonctionnel est complexe et les entités nombreuses, une nausée est vite arrivée chez le développeur.

Dans mon cas, la BDD était le fil rouge, le processus (dev Java) s’adapte à la BDD et pas l’inverse.

Afin de garder la logique de la nomenclature et faciliter sa maintenance, nous avons modifiés:
1- le nom des tables dans notre SGBDR favori
2- le nom des classes java
3- le nom de nos entités (@Entity(name = “myEntityName”))
4- nos requetes *QL

Le point 1 a pour partie sensible de ne pas faire de faute de frappe (jusque là, ca va)
Le point 2 a la même partie sensible que le point 1, le refactoring Java est simplifié par des EDI comme Eclipse et la compilation nous alerte et pointe les oublis et autres erreurs humaines.
Le point 3 a la même partie sensible que le point 1
Le point 4 ne pourra être testé que par des tests unitaires (mais une appli est rarement couverte à 100%) ou en recette (rarement couvert aussi à 100%).

Dans le cas du point 4, comment s’assurer rapidement d’une non régression?
La vérification des entités de NamedQuery permet d’éviter des oublis de non modification dans nos requêtes JPQL, sans attendre l’exécution de la requête.

@Alain, bien souvent, on mappe une table à une entité et réciproquement:
@Entity
@Table(name=”EXEMPLE”)
public class MaClass {
…
}