Dépendance en cascade

Bonjour,

j'ai 3 modules maven : A,B,C (plus leur parent, D)

A est la partie View de mon appli, B le controller et C le model

A s'adresse à B, qui contrôle la session et les autorisations de l'utilisateur et, si tout ce passe bien, envoie la requête vers C, sinon, génère une exception.

A dépend donc de B, qui lui-même dépend de C.

Or, il semble que A dépendent également de C, par une sorte de cascade de dépendance, ce qui fait que je peux appeler des classes C dans A, ce qui l'encontre de ma structure MVC dans laquelle A ne peut s'adresser à C sans passer par B.

Pour résoudre ce problème, j'ai créer une exclusion de C dans la dépendance vers B du pom.xml de A, comme suit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<dependency> <groupId>project</groupId> <artifactId>B</artifactId> <exclusions> <exclusion> <groupId>project</groupId> <artifactId>C</artifactId> </exclusion> </exclusions> </dependency>

---

Tout va bien, impossible d'utiliser les classes de C dans A. Mais le problème, c'est que du coup, mes requêtes A->B->C ne fonctionnent plus, il semble qu'elles sont stopper dans B.

Quelqu'un aurait une idée pour résoudre ce problème?


Merci !
(J'espère avoir été clair...)

Je crois que tu confond la logique de ton code (A ne doit pas s'adresser à C) et la logique de dépendance (qui permet à ton application de tourner). Si B s'adresse à C, il est inévitable que C devra se trouver dans l'application finale, et donc A devra inclure C (par le phénomène de dépendance transitive).

Pour la partie A ne s'adresse jamais directement à C, c'est surtout une question d'autocontrole, c'est en dehors du rôle de maven. ;)

(un peu tard, désolé, j'étais sur un autre projet)

Je ne doute pas de ma capacité d'auto-contrôle, là n'est pas le problème, il s'agit plutôt de mettre en place et respecter certaines règles fondamentales qui garantissent la sécurité du projet.

Je trouverai étonnant que maven n'ai pas implémenté un système permettant une séparation stricte des différents modules, même quand ils sont liés par un module tiers. Par exemple, avoir un parent commun ne lie pas les modules ensembles.
Si c'est le cas, ben c'est bien dommage...

Il est difficile de comprendre exactement ce que tu cherche.

Si j'ai A qui dépend de B qui lui même dépend de C


que j'ai une méthode B qui a grosso modo le code new C();

et que j'appelle cette méthode depuis A. Si maven exclu C et en supposant que le programmeur a bien travaillé (B n'expose pas C à A), je vais avoir un problème à l'exécution. Le code de B renverra un ClassNotFoundException. Or on a besoin d'exécuter B dans les Test de A, sinon A repose sur du vent :)

Maintenant, en gardant ces emmerdes à l'esprit, il existe dans maven le système d'exclusion. Quand tu met que A dépend de B, tu peux mettre que A dépend de B mais qu'on exclu la dépendance transitive A.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<dependency> <groupId>....</groupId> <artifactId>B</artifactId> <version>....</version> <exclusions> <exclusion> <groupId>....</groupId> </artifactId>C</artifactId> </exclusion> </exclusions> </dependency>

---

Mais les exclusions sont en général utilisées quand on dépend d'une librairie trop gourmande et qui a déclaré des dépendances inutiles. Ca permet de corriger le tire après coup.

L'alternative, dans le pom de B, c'est de déclarer la dépendance B => C optionelle. Du coup tout projet dépdendant de B n'aura pas automatiquement la dépendance à C.
Mais de toutes façons, rien n'empechera la programmeur de rajouter A à son pom. Et attention, cette dernière méthode porte bien son nom. Normalement elle s'utilise quand B peux quand même tourner même si C n'est pas disponible.


Ton nerf de la guerre ici, c'est l'exécution et, tu va vite te retrouver emmerdé par tes tests unitaires.


Idéalement, pour les gros truc, la division serait plutot


CApi
Cimpl => CApi
BApi
Bimpl => BApi, Cimpl (scope = test)
A => BApi (du coup a ne voit pas l'implémentation B et par conséquent ne peux même pas savoir qu'elle nécessite C) + Bimpl (scope=test) (du coup B et C deviennent visible uniquement pour les unit test).

et évidement le projet d'intégration
Intégration => Cimpl, Bimpl, A

Avec ca au moins: tu dispose de C pour tes test. Et à la compil seul BApi est visible => aucune classe de C ne peux être utilisée directement par A.
Je ne sais pas si ces propositions répondent à tes questions.

Merci pour tes réponses

Je vais essayer d'expliquer plus à fond mon architecture.

C est un webservice, construit autour d'une database sensible. C reçoit des requêtes et doit les traiter.
B est le module d'entrée du webservice, chargé de contrôler l'identité des utilisateurs, via spring security.
A est une interface graphique.
L'idée, c'est qu'il y aura aussi une communication avec des éléments externes (autre database, autre serviceweb) et qu'il me paraissait judicieux de prévoir un module chargé de la sécurité de l'accès au webservice, que les requêtes proviennent de ma propre interface graphique, ou de services externes.
Quand une requête arrive dans B, B contrôle si l'utilisateur est connecté, et, si c'est le cas, envoie la requête vers C. Or, les classes-fonctions de B et de C ont pratiquement le même nom, histoire de faire plus simple (en soit, les classes de B fonctionnent comme des sortes d'interfaces). Le risque, totalement implicite à la programmation, est d'appeler les classes de C à la place de celles de B, ce qui met en danger tout le programme.

Alors, tu vas me dire, t'as qu'à être attentif, ou nommer tes classes différemment, mais comme il s'agit d'un gros projet sur lequel on risque de se retrouver à plusieurs à travailler, je peux pas me permettre de prendre le risque que quelqu'un d'autre faire le même genre d'erreur et appel une classe DAO depuis l'interface.

DONC, pour résumé, je voudrais que quand j'appel une classe de C dans A, mon IDE me dise qu'il ne trouve pas cette classe, quand bien même il y a accès indirectement via B.

Voilà, j'espère que c'est plus claire comme ça

Citation:

---

Si maven exclu C et en supposant que le programmeur a bien travaillé (B n'expose pas C à A)

---

==> j'ai pas bien compris ce que tu voulais dire par làk mais il y a un peu de ça

Et j'ai pas compris ton explication final : quelle différence entre API-Impl dans le contexte de Maven? Si j'ai bien compris, tes API jouent le rôle d'interface au niveau maven? (désolé si je fais preuve de crétinerie avancée, je suis pas ce qu'on peut appeler un spécialiste de maven)

je ne comprend pas. Si je suis ta structure, C ne devrait même pas etre dans ton applicaiton 8O C étant un web service, il tourne sur un serveur, et c'est de ce coté là que le check sécurité se fait (via spring security).

Ton application A aura juste besoin d'un client pour ce webservice, (CClient) qui ne dépendra au final que des Socket java (plus soap et une série d'autres trucs bien utiles), mais jamais il ne pourra attaquer le webservice sans passer par le réseau :? Donc je ne comprend pas comment un programmeur pourrais arriver à contourner la sécurité.

Maintenant, si tu as mis en place la sécurité coté applicatif et que ton webservice est ouvert derrière à tous vents.... Je crois que tu as un plus sérieux problème à prendre en compte que tes programmeurs :aie:


Maintenant, d'une manière générale, je verrais ton code comme ceci:

ServiceAApi (je n'ai pas dit webservice) -> fournis des méthodes de data destinées à l'interface (c'est une moitié de ton B actuel)

ServiceAImpl -> implémente ça avec de la sécurité sur un webservice (c'est l'autre moitié de ton B actuel, celle qui fait quelque chose)

ClientInterface -> Dépend de serviceAApi, ne vois que lui et s'en sert pour sa communication. Bien sur, il te faudra un implémentation "mock" pour tester le code. Impossible donc d'accéder à ServiceAImpl et donc au webservice derrière directement. Le compilateur ne les connait pas.Avantage supplémentaire, tu est certain que les développeur ne peuvent jamais attaquer "par erreur" la db , uniquement leur mock local ^^

ClientIntegration -> Dépend de ClientInterface et utilise l'implémentation ServiceAImpl, n'a pas de code et constitue le livrable pour l'utilisateur final.

Je suis d'accord avec les réponses de tchize, ça sonne étrange ton truc sur C étant des webservices mais devant être livré.
Si on imagine la même chose avec C qui est de simples services et non des webservices, alors il y aurait la possibilité de jouer sur le scope des dépendances. Dans ce cas, B aurait besoin de C pour compiler, mais A n'aurait pas besoin de C pour compiler, juste pour le runtime.

A voir tout de même que le rôle de Maven n'est pas de faire du check de qualité de code ni de t'aider à cloisonner vraiment ton code.
Pour ce genre d'objectif, je te conseille de te faire des "tools" de contrôle de qualité que tu peux passer régulièrement, voire intégrer au build sous forme de tests (par exemple vérifier que dans ton répertoire du projet A, il n'y a pas de fichier .java qui contienne des import C.xxx)

Ok, encore une fois mes explications étaient pas très claires...

Les 3 modules se trouvent sur un même serveur (logique), l'accès depuis les services externes se fait via mon module B, et non pas C, et seul B communique avec C (c'est la porte d'entrée, en quelque sorte).
Les requêtes destinées à récupérer/modifier la DB proviennent soit de mon interface (A), soit de l'extérieur, et arrive dans le module B qui contrôle si la requête provient d'un utilisateur connecté (via le context de spring security ou une clé d'accès pour les requêtes extérieures).
C'est l'ensemble B+C qui est le webservice, mais pour économiser des parsemage/déparsemage en Json, l'interface principale se trouve également dans le même projet, et je cherche donc à garantir que A doit bien passer par B pour accéder à C (comme cela sera obligatoirement le cas pour les services externes, vu que les requêtes REST arriveront sur le module B)

Citation:

---

Pour ce genre d'objectif, je te conseille de te faire des "tools" de contrôle de qualité que tu peux passer régulièrement, voire intégrer au build sous forme de tests (par exemple vérifier que dans ton répertoire du projet A, il n'y a pas de fichier .java qui contienne des import C.xxx)

---

Effectivement, ça peut être une solution viable

Citation:

---

Envoyé par chtig

A voir tout de même que le rôle de Maven n'est pas de faire du check de qualité de code ni de t'aider à cloisonner vraiment ton code.
Pour ce genre d'objectif, je te conseille de te faire des "tools" de contrôle de qualité que tu peux passer régulièrement, voire intégrer au build sous forme de tests (par exemple vérifier que dans ton répertoire du projet A, il n'y a pas de fichier .java qui contienne des import C.xxx)

---

+1 le lifecycle de maven est suffisement souple que pour y ajouter tes propres plugins de controle qualité ;) Mais c'est du boulot. Il existe aussi pas mal de plugins genre checkstyle dont une des possibilité est de rendre illegal certains imports:
http://maven.apache.org/plugins/mave...kstyle-plugin/

et pour ajouter la gestion des imports dans le checkstyle:
http://checkstyle.sourceforge.net/co...#IllegalImport