je suis en train de travailler sur la « bundlisation » de JTheque Core. Comme le core proposait un certain nombre de services, j’ai commencé par découper le gros jar qu’était le core en une série de bundles offrant tous un service bien précis.

Je me suis vite rendu compte que le découplage de mes différents services était à peu près nul. J’avais un nombre énorme de dépendances pour chaque bundle et pire encore, j’avais un grand nombre de dépendances cycliques, soit directs soit indirects.

Pour information, une dépendance cyclique directe est une situation dans laquelle un bundle X dépend d’un bundle Y qui dépend lui-même de X. Une dépendance cycle indirecte est la situation dans laquelle X dépend Y, Y dépend de Z et Z dépend de X. Je parle ici de bundles, mais cela peut concerner des projets, des classes ou des packages.

A noter que les différentes techniques que je vais présenter s’appliquent également pour des dépendances entre composants non-OSGi, les principes sont tout à fait les mêmes.

Dans le cas de packages à l’intérieur d’une même application, même s’il faut éviter cela, il est possible de vivre. Néanmoins, dans le cas de bundle ou de projets, il n’est en général même pas possible de builder l’application. Dans mon cas, les bundles sont des modules Maven. Il est donc impossible de lancer le build d’un bundle dans un cycle puisqu’il faut builder le premier bundle avant le second et le second avant le premier, ce qui n’est pas évidemment pas possible.

En plus d’être très mauvais dans un système de build, les dépendances cycliques entre componsants sont aussi un énorme problème de conception. En effet, on ne peut plus travailler sur le bundle A sans travailler sur le bundle B et vice-versa. En plus de cela, les deux composants sont très difficiles à faire évoluer de manière saine.

Les dépendances cycliques au niveau des classes à l’intérieur d’un composant ne posent pas vraiment de problèmes. On est toujours dans le même composant, les classes peuvent dont être liées de manière cyclique, même s’il faudrait tout de même éviter cela dès que c’est possible (ça ne l’est pas toujours).

Pour en revenir à JTheque, j’ai donc du résoudre ce problème de dépendances cycliques avant de pouvoir avancer plus loin. Il existe beaucoup de techniques permettant de faire cela. Voici les différentes pistes que j’ai explorées pour résoudre ces dépendances. A noter que ces techiques ne permettent pas seulement de règler le problème des dépendances cycliques mais permet aussi d’améliorer l’architecture de son application.

1. Déplacer les classes au bon endroit : Dans certains cas, j’avais des classes dans un bundle alors qu’elles n’avait rien à y faire. Dans ce cas-là, il peut suffir de les dépacer dans un autre bundle. A noter que ce cas est le plus simple à résoudre et que ce n’est malheureusement pas le plsu courant. En plus de cela, dans le cas ou la/les classes à déplacer sont dépendantes d’autres bundles, il est possible que cela crée de nouvelles dépendances cycliques. Un exemple est une classe de gestion de modules qui était contenues dans le bundle d’interfaces graphiques.

2. Déplacer les fonctionnalités : J’ai également trouvé beaucoup de fonctionnalités, typiquement des fonctions, à l’intérieur d’un bundle qui n’étaient pas au bon endroit. Par exemple le bundle « modules » permettait de faire des mises à jour alors qu’un bundle « update » existait. Il m’a suffi de déplacer cette fonctionnalité de mise à jour vers le bundle update pour résoudre ma dépendance.

3. Fonctionnalités mal découpées : Il arrive souvent qu’une fonctionnalité, généralement une méthode ou une classe, fasse trop de choses et entraîne des dépendances qui ne sont pas bienvenues ici. Souvent bien redécouper les fonctionnalités et donc le rôle de chaque classe/méthode peut suffir à régler le problème. A noter que ceci ne concerne pas uniquement les concepts de dépendances, mais est un principe de base de la conception orientée objet. Dans le cas de JTheque, j’avais pas par exemple, une permettant permettant de choisir une collection qui retournait true si on pouvait ouvrir la collection avec le couple login/password entré sinon false. Mais en plus de cela, elle affichait une erreur dans la vue de choix de collection s’il y avait un problème alors que ce n’était pas du son rôle. J’ai mis à jour cette méthode pour qu’elle ne fasse que tester si on pouvait ouvrir la collection ou non et j’ai implémenté l’affichage de l’erreur au niveau de l’action Swing.

4. Découper les fonctionnalités du bundle : Il peut arriver que le bundle fasse trop de choses ou ait plusieurs aspects bien distincts. Dans ce cas, il faut tout de suite séparer le bundle en plusieurs autres pour que chacun ait une responsabilité claire. Souvent cela va aider à résoudre une dépendance cyclique, comme moins de bundles auront des dépendances vers chacun des nouveaux bundles et que chacun des nouveaux bundles devrait avoir moins de dépendances vers d’autres bundles. Mais cela peut également introduire de nouveaux cycles car on peut mal séparer les composants et se retrouver avec 2 composants cycliquement dépendant, on n’aura alors fait que déplacer le problème. Dans JTheque, j’ai découpé le modules vues en 2 deux bundles : vues et ui. Le module vues contient l’implémentation des vues de JTheque alors que le module ui contient des classes utilitaires pour la création de vues ainsi que des composants Swing génériques qui peuvent être utilisés ailleurs.

5. Introduire un système de CallBack : Un système de CallBack est un simple système de listeners qui peut permettre de résoudre des dépendances. Au lieu qu’un bundle avertisse directement un autre bundle, il suffit que le second s’enregistre sur le premier comme listener. Ainsi le premier n’a plus besoin de connaître le second. On voit tout de suite que les listeners sont donc plus puissants qu’on ne pourrait le croire au premier abord. Dans le cas de JTheque, j’ai implémenté cela pour le choix des collections. En effet, de base, le gestionnaire de collections appelait directement la vue pour dire que la collection avait été choisie. En passant à un listener, cela est beaucoup plus souple et le gestionnaire de collections avertit automatiquement tous les écouteurs. En plus de cela, si j’ai besoin plus tard d’ajouter un second écouteur, je n’ai rien à changer du côté du bundle collections.

6. Séparer la spécification de l’implémentation : Comme il n’est pas toujours possible de supprimer les dépendances cycliques directement, on peut donc les contourner en séparant la partie de spécification de la partie d’implémentation. Cette technique n’est clairement pas la meilleur mais peut parfois être utile quand il est vraiment difficile de résoudre le cycle. On sépare donc dans un bundle toute la partie spécification qui est appelée de l’extérieur et la partie d’implémentation qui peut alors avoir des dépendances avec l’extérieur. A noter que ce n’est clairement pas souvent faisable en l’état car il n’est pas toujours possible de complètement séparer l’implémentation de la spécification sans cycles. Je n’ai pas utilisé cette technique dans JTheque, mais j’y ai pensé.

7. Regrouper 2 bundles en un seul : Dans certains cas, on se rend compte que deux modules sont si intrinsèquement liés qu’ils ne forment en fait qu’un seul modules. Dans ce cas, la meilleure solution est de les regrouper en un seul bundle.

Voilà, j’ai maintenant passé en revue les différentes techniques que j’ai utilisées pour résoudre les dépendances cycliques dans les bundles de JTheque Core. Il en existe très certainement de nombreuses autres, mais personnellement, elles m’ont suffit.

J’espère que cela pourra être utile aux personnes cherchant à résoudre des problèmes de dépendances cycliques.

Just a little to inform you that i’m currently migrating JTheque Core to OSGI / Spring Dynamic Modules. The core will be fractioned into several bundles. The JTheque Modules will also be OSGi bundles.

It will increase the modularity of the different services of the Core. And it will also be a more standard way to develop modules. And last but not least, it’s an opportunity for me to learn OSGi and Spring Dm.

Baptiste

Une petite nouvelle pour l’avancement du projet JTheque.

J’ai commencé à migrer JTheque Core vers un environnement OSGi et Spring Dynamic Modules. Le core sera désormais séparés en plusieurs bundles par fonctionnalité.

Les modules seront aussi des bundles OSGi.

Ce changement permettra d’améliorer la modularité des différents éléments du core et de suivre une voie plus standarde pour la création de modules.

J’espère que cela permettra d’améliorer la qualité de JTheque Core. C’est également une occasion pour moi d’apprendre à utiliser OSGi et Spring DM.

Baptiste

Je viens de mettre en ligne un nouveau design pour le site de JTheque : http://jtheque.developpez.com.

J’ai repris le design utilisé sur mon site personnel. Le site est toujours généré avec Maven 2, mais j’ai créé un skin Maven personnalisé pour utiliser mon propre design.

En espérant que cette version du site soit plus agréable que la précédente.

I’ve made a new design for the JTheque web site : http://jtheque.developpez.com/en

I took the same design than for my personal web site. The web site is still generated with Maven 2, but i use a custom maven skin to generate the site.

I just written a new article : Develop a modular application with JTheque Core 2.0.3

In this article, we will see how to develop a Java modular application with JTheque Core 2.0.3. We will develop an applications and 2 modules.

Hope that wil be useful.

Je viens de mettre à jour mon article : Développer une application modulaire avec JTheque Core 2.0.3

Pour prendre en compte les changements de la nouvelle version 2.0.3. Cette dernière simplifie grandement la déclaration du fichier application.xml ainsi que la création d’applications et de modules JTheque. En plus de cela, le support de Swing a été amélioré et la déclaration de menu est devenue beaucoup plus parlante.

En espérant que ce soit utile pour quelques uns d’entre vous.

I finished the development of JTheque Movies 1.0

This application enable the user to manage a collection of movies and to read them directly in the application. For this last functionality, on Windows, you need Windows Media Player and on Linux you need VLC Media Player as web plugin. The user interface has been completely remade to be more esthetic.

Here are two screenshots of this new versions.

You can download the both versions here :

• Windows Version
• Linux Version

This version integrate this modules :

• JTheque Movies Module 1.3
• JTheque Memory Module 1.4.1
• JTheque Tools Module 1.0.2

All the sources of this modules and of the core (JTheque Core) are all availabes under GPL V3 on the project management system (here (French)).

I hope that this program will be useful for somebody.

Je viens de terminer le développement de JTheque Movies 1.0

Cette application permet de gérer une collection de vidéos et depuis cette version de les lire directement depuis l’application. Pour cette fonctionnalité, il faut que Windows Media Player soit installé sous Windows et que sous Linux VLC Media Player soit installé comme plugin web. L’interface graphique a également été complètement revue depuis les anciennes versions.

Voici 2 screenshots de cette nouvelle version :

Vous pouvez téléchargez les deux versions ici :

• Version Windows
• Version Linux

Cette version intègre les modules suivants :

• JTheque Movies Module 1.3
• JTheque Memory Module 1.4.1
• JTheque Tools Module 1.0.2

Les sources de ces modules ainsi que du coeur (JTheque Core) sont toutes disponibles sous licence GPL V3 sur le gestionnaire de projets.

En espérant que ce programme soit utile à certains à d’entre vous

J’ai le plaisir de vous annoncer la sortie de la version 2.0.2 de JTheque Core.

Cette version compte plusieurs changements majeurs. Notamment la suppression de la distinction entre module primaires et simples. Cette notion est remplacée par la notion d’application, déja existante. En plus de cela, cette version corrige plusieurs bugs et améliore les performances générales de l’application.

Vous pouvez trouver une liste exhaustive des changements ici : http://projets.developpez.com/versions/show/107

Vous pouvez télécharger les différents fichiers du projet ici : http://jtheque.developpez.com/utilities/core/download.html

Pour développer une application avec cette version, il faut télécharger le fichier dev-base-2.0.2.zip.

Je vais mettre à jour dès que possible mon tutoriel sur le développement d’applications avec JTheque pour prendre en compte les modifications cette version.

Voilà