[RCP] Architecturer une application sous Netbeans Platform

Bonjour,

Je dois re-concevoir une application en réutilisant la plateforme de Netbeans.
La version existante est composée de plusieurs modules (chacun ayant son exécutable). On a un module de gestion général, un module de saisie et un module de calcul. Chacun travail avec la même base de données et manipule donc des objets (pojo) communs.

Je débute avec le monde du RCP et je me demandais comment je pouvais modéliser mon appli, pour avoir qqs chose de facile a maintenir et d'évolutif ?

Pour détailler un peu plus l'architecture, l'appli est découpé en 2 parties : présentation, métier/persistance.
C'est une application full desktop, avec seulement la base de données qui est délocalisée sur un serveur. Mon code métier et mon code de présentation seront donc dans la plateforme !

Avec Netbeans, on peu allègrement utiliser la gestion des modules, il sera alors évident que chaque module de l'ancienne version aura son module sur la plateforme.
Mais je me posais les questions de comment pousser plus loin le concept :
Faut il que aussi je découpe mes différentes parties en modules ?
Faut il que je crée un module dédié pour mes POJO et fichiers de mapping ?

Merci de votre expérience dans ce domaine

Alors, oui. Le mieux est de dissocier la couche présentation de la couche métier. Et donc d'avoir des modules bien séparés pour cela.

Avec NetBeans, il faudra dire que ton(tes) module(s) de présentation dépend(ent) de ton(tes) module(s) "metier".

Et oui, le mieux est de créer un module séparé qui contiendra tes POJOs et d'indiquer que les autres modules dépendent de celui-là.

Je pense que c'est la meilleure façon de travailler. En tout cas, c'est comme cela que je le ferais, si c'était à moi de le faire. D'ailleurs, au travail, nous travaillons de cette façon modulaire, où nous retrouvons presque un JAR pour chaque type de travail bien précis. Toi, tu auras un nbm pour chaque module.

Aussi, NetBeans demande à ce que les 3rd party jar soient également enveloppés dans des nbm. Par exemple, si tu utilises commons-io de jakarta, et JFreechart, tu peux les mettre tous les deux dans le même nbm, ou chacun séparément. Le mieux est d'avoir un nbm par 3rd party jar. Ca demande un peu plus de travail, mais ca permet de mieux gérer les dépendances entre les modules. Et de ne charger que les modules qui sont nécessaires.

Bonne chance.

P.S. Si tu pouvais partager avec nous tes impressions sur le RCP de NetBeans, ou même écrire un (court) article à ce sujet, ce serait vraiment super.

Vincent

Sympa pour cette réponse rapide.
Tu me reconfortes dans mon idée de départ, j'ai plus qu'a me lancer :)

Ca tombe bien que tu me lances sur les 3rd party jar, je me posais une question a ce sujet.
J'avais bien compris que chaque jar tiers devait être "encapsulé" dans un nbm distinct (merci au bon tuto sur le site de netbeans)
Mais alors que je créer un nbm pour hibernate, je me demandais s'il je devais vraiment créer un nbm pour chaque dépendance ou si fallait mieux juste les rajouter au classpath.

Je pense qu'un nbm est quand même mieux, ca facilite le déploiement des mises a jour, bien que la démarche est un peu lourde a mettre en place, en déclarant toutes les dépendances de modules partout (netbeans 5.5 ayant un "tout petit peu" simplifier la méthode).

Encore merci pour tous ces compléments d'information.

PS : Je ferais volontier un petit article sur Netbeans Platform quand j'aurais un peu plus de recule (et quans son adoption sera validé)

Il est facile d'inclure les librairies tierces en créant des "Library Wrapper Module".
Tout tes modules (les tient + les tierces) tu les ajoutes au sein de ce qu'on pourrait appeler un projet d'application "Project Suite Module".

Le découpage par module (présentation / metier) et une bonne chose et permet de mieux structurer ton code.

Les "Library Wrapper Module" sont facile a créér mais peuvent poser quelques soucis:

1. Quand tes librairies ont des dll et autres bibliothèques natives, je ne sais pas trop comment faire.
2. Mettre à jour une "Library Wrapper Module" n'est pas super-aisé.

Mais l'architecture des modules de Netbeans est bien fichue.

Salut divxdede,

Merci de m'avoir corrigé, c'est bien des wrapper dont je parlais et non de simple nbm. L'inconvénient des wrapper vis a vis du classpath, c'est de devoir déclarer toutes les dépendances entres le module.

Exemple, j'ai mon module métier qui intégre le gestionnaire de persistance Hibernate et pour simplifier son utilisation, je vais utiliser Spring.
il faut alors créer deux wrappers sur les bibliothèque d'Hibernate et de Spring, et signaler la dépendance de mon objet métier sur ces deux warppers. Maintenant, le package ORM de Spring utilise le package Hibernate lui aussi, il alors déclarer une nouvelle dépendance.
Imaginez maintenant le bronx quand on va utiliser des bibliothèques style log4j qui vont avoir des dépendances de partout :)

Maintenant ce petit désagrément est largement compensé par les avantages qu'offrent les wrappers au niveau de la sécurité et la décision faite lors du chagrment de la bibliothèque associée.

Sinon la mise a jour ne sait pas comme un nbm vu que structurellement c'est quasiment la même chose ?
Je vais chercher plus d'info la dessus.

En tout cas, le projet a été validé, je vais donc pouvoir le lancer sur la dev de la plateforme :D

L'avantage de l'enrobage fait par le Library Wrapper Module et de pouvoir attacher une "signature" au module.

Ainsi Netbeans sera capable de creer le déploiement JavaWebStart correctement "signé" pour être déployable sur le web sans intervention majeur de la part du développeur.

Bonjour,

Me voila confronté a mon premier problème autour des modules.
J'ai créé un premier nbm contenant les classes pojo. Rien de bien méchant, la compilation passe nikel et mon jar est créé dans le rep /build/cluster/module.
Ensuite j'ai créé un deuxième module pour mon métier (persistance, etc...) et je crée une dépendance vers mon premier module pour pouvoir utiliser mes pojo.
Domage ca ne fonctionne pas, il ne me trouve pas mes classes :(

Alors comment on fait pour qu'un module puisse travailler avec les classes d'un autre module appartenant au même cluster ?

Citation:

---

Envoyé par Jamatic

Bonjour,

Me voila confronté a mon premier problème autour des modules.
J'ai créé un premier nbm contenant les classes pojo. Rien de bien méchant, la compilation passe nikel et mon jar est créé dans le rep /build/cluster/module.
Ensuite j'ai créé un deuxième module pour mon métier (persistance, etc...) et je crée une dépendance vers mon premier module pour pouvoir utiliser mes pojo.
Domage ca ne fonctionne pas, il ne me trouve pas mes classes :(

Alors comment on fait pour qu'un module puisse travailler avec les classes d'un autre module appartenant au même cluster ?

---

Dans ton module de classes POJO, il faut indiquer quels sont les packages "public" ==> C'est a dire les packages visibles des modules dépendants.

C'est dans la partie "API Versioning"

Yes cool, ca marche :D
Ca m'apprendra a survoler un peu trop vite les boites de dialogues :lol:

Merci divxdede

Re moi,
Bon finalement, ces histoires de dépendance sont pas si claire pour moi que ce que je croyais !

Exemple : J'ai un module M1 qui fera de la persitance via JPA + Spring.
Ma classe dao MonDaoJpa hérite alors de JpaDaoSupport du package spring-jpa.
Je crée un wrapper sur ce package et je déclare une dépendance depuis mon module M1.

Maintenant la classe JpaDaoSupport se base sur la classe DaoSupport d'un autre package, spring-dao.
J'ai donc créé un nouveau wrapper sur ce package et déclaré une dépendance de spring-jpa vers spring-dao.
Hors mon module M1, me dit qu'il ne trouve pas la classe DaoSupport.

Alors, je sais pas quoi faire.
Mettre une dépendance aux deux endroits, que dans mon module M1 ?

J'avoue ne plus saisir la logique
Svp :)

Alors ce matin je suis tombé sur un bon article traitant de la gestion du classpath dans les modules :
http://www.netbeans.org/download/dev...classpath.html

Ma manipe de faire dépendre un module A du module B, puis faire dépendre le module B du module C, pour acceder aux classes du module A dans le module B, ca ne fonctionne pas ! :lol:
Il n'y a pas de notion de dépendance transitive.
Donc la solution est déclaré A et B dans C et c'est tout. Surtout que c'est logique car les dépendances entre A et B ont déjà été effectuées durant leur compilation, le principale étant qu'elles soient chargés dans le classpath.
C'est tout de même domage de pas pouvoir mettre plusieurs jar dans un même wrapper !

J'ai bien vu que l'on pouvait créer des "J2SE Librairy Descriptor" pour intégrer des jars dans un module. Un solution serait alors de créer un nbm avec un ensemble de jars et le faire dépendre dans les modules qui en ont besoin. Mais ca peut poser des problèmes avec les licences, etc ...

Voilou, si quelqu'un a quelque chose a apporter en plus de ca, moi j'en suis prenneur :)

Effectivement les dépendances ne sont pas transitives... ce qui est bien dommage. Du moins le GUI de netbeans pour pallier à ce problème de transitivité devrait proposer de ramener toutes les dépendances (ou parties)

Par contre il est possible dans un library wrapper module de "monter" plusieurs jars !

Citation:

---

Envoyé par divxdede

Par contre il est possible dans un library wrapper module de "monter" plusieurs jars !

---

Alors apres avoir parcouru la doc de netbeans et les boites de dialogue de long en large, j'ai trouvé ma soution, sur google :)
Par contre netbeans ne propose aucun assistant, pour le moment, faut le faire à la mano !

Pour ceux que ca intéresseraient :

1. On crée un premier module wrapper avec une des librairies à intégrer.

2. Dans le répertoire /release/module/ext du module fraichement crée et qui contient une copie de la première librairie, on copie les autres librairies désirées.

3. Dans netbeans, on édite le fichier Project Metadata pour y rajouter autant d'entrées class-path-extension que de librairies copiées. example

Code:

---

1 2 3 4

<class-path-extension> <runtime-relative-path>ext/library1.jar</runtime-relative-path> <binary-origin>release/modules/ext/library1.jar</binary-origin> </class-path-extension>

---

4. Enfin pour éviter de tout se taper à la main, on peut maintenant aller dans les propriétés du module et définir tous les packages suppémentaire avec une portée publique.

5. Il reste à recompiler le module et à déclarer les dépendances dans les autres modules qui en ont besoin


Je conseil tout de même d'utiliser cette solution avec parcimonie, seulement dans le cas ou il y a un véritable intéret. Exemple dans mon cas pour avoir un seul wrapper avec les 4 bibliothèques permettant de faire du Hibernate EntityManager.
En effet, il ne faudrait pas risquer d'avoir des bibliothèques inutiles au chargement d'un module.

Me voila un peu soulagé :D

Au fait, j'ai dit une grosse bourde avec la réponse du dessus, car il suffit de selectionner plusieurs librairies à la création d'un wrapper pour ajouter plusieurs librairies d'un seul coup.
Dans le champ de saisie, elles sont séparées par un ";"

Citation:

---

Envoyé par N©O

Au fait, j'ai dit une grosse bourde avec la réponse du dessus, car il suffit de selectionner plusieurs librairies à la création d'un wrapper pour ajouter plusieurs librairies d'un seul coup.
Dans le champ de saisie, elles sont séparées par un ";"

---

Ce que je te disais le message au dessus :) c'est possible d'en selectionner plusieurs

Oui je ne l'avais pas compris dans ce sens ;)
Et comme ca, on sait aussi comment rajouter (ou retirer) des librairies meme apres le wrapper crée :)