En lisant un bon article sur les fichiers *.product (Create a product configuration), je me suis dit que je n’avais jamais écrit sur la manière dont Eclipse Scout les utilisait.

Une application Eclipse Scout propose par défaut deux manières de lancer chaque application (le serveur, et chaque client). S’il n’existe côté client, qu’une seule application (reposant sur SWT par exemple), cela fait tout de même 4 lanceurs différents:

Ce mécanisme repose sur les fichiers *.product et n’est pas si difficile à comprendre.

Pour chaque application, Eclipse Scout se propose de définir un fichier product «dev» et un fichier product «prod». Le fichier «dev» est pensé pour l’exécution à partir d’Eclipse. Le fichier «prod» est pensé pour la compilation.

Avec chaque fichier *.product se trouve également le fichier config.ini qui sera utilisé (il est référencé dans le fichier *.product. Le fait qu’il se trouve dans le même dossier est une simple convention).

Même si comme le mentionne l’article de Patrick Paulin il est possible d’utiliser le même fichier pour l’exécution et la compilation, faire la distinction entre les deux apporte plus de flexibilité.

Serveur: Jetty vs war
Dans l’application serveur, le produit «dev» va inclure les composants nécessaires (jetty) pour fonctionner de manière autonome. Le produit «prod» est quant à lui pensé pour un servlet container comme tomcat (on obtiendra un fichier war).

Reglage du port
Bien souvent le port 8080 est occupé par le serveur tomcat. Aussi il peut être pratique de tester son application à partir d’un autre port. Côté serveur, un paramètre dans le fichier config.ini va indiquer à Jetty sur quel port il doit travailler.
Fichier: {{application_scout}}.server/products/development/config.ini

Côté client, un paramètre va indiquer l’url du serveur:
Fichier: {{application_scout}}.client/products/development/config.ini

Il suffit que le client et le serveur soient réglé de manière compatible pour que cela marche sur n’importe quel port. (nb: voir ce commit)

Laisser des placeholders dans le fichier de config
Bien souvent, en tant que devellopeur, il faut laisser des placeholders dans les fichiers de configuration. Au moment de l’installation, ils seront remplacés avec les vraies valeurs (peut-être même de manière différente s’il s’agit d’une installation en production ou sur l’environnement d’intégration).

Pour cela, les fichiers de config «prod» sont génériques et contiennent ces chaines de caractères qui seront remplacées plus tard.

D’autres lanceurs
Il est évidement possible de créer d’autres fichiers. Par exemple, j’ai un fichier *.product pour lancer mon serveur sans base de données. Voir: Un fragment NoDB pour le serveur de mon application Eclipse Scout