web-dev-qa-db-fra.com

jaxrs-api VS jsr311-api VS javax.ws.rs-api VS jersey-core VS jaxrs-ri

J'ai cherché sur Google un peu, mais je ne sais toujours pas exactement ce que chacun de ces moyens signifie exactement.

Voici ma compréhension de cela:

  • jaxrs-api: contient uniquement des api. Aucune implémentation. Mais en quoi est-il différent du JSR311
  • jsr311-api: JSR311 c'est une demande de spécification. Ce qui signifie que c'est censé être un document. Pourquoi est-ce donc un pot?
  • javax.ws.rs-api: Est-ce une implémentation?
  • jersey-core (/ jersey client): Est une implémentation de JSR311.

J'ai téléchargé chaque pot et j'ai essayé de décompiler et de voir ce qu'il y a dedans, mais je ne peux trouver que des interfaces dans chacun d'eux et non l'implémentation.

Je suis confronté à ces questions dans le contexte des avertissements en double générés par le plugin maven shadow, et j'ai besoin d'une bonne compréhension de ce qui précède pour savoir lesquels exclure et pourquoi.

restjerseyjax-rsjsrjsr311
27
Gadam

Je vais d'abord passer à la question

"JSR311 c'est une demande de spécification. Ce qui veut dire que c'est censé être un document. Pourquoi alors est-ce un bocal?"

Sauf le dernier (jersey-core), tous ces pots sont des pots de "spécification". Les spécifications JAX-RS (ainsi que de nombreuses autres Java) définissent les contrats (ou interfaces) pour lesquels les implémenteurs doivent implémenter le comportement spécifié.

Donc, fondamentalement, toutes les classes spécifiées dans la spécification doivent être dans le pot en tant que contrats. Les utilisateurs finaux des pots peuvent les utiliser pour les contrats. mais il n'y a pas de mise en œuvre. Vous devez avoir une implémentation réelle pour exécuter l'application, bien que le pot API spécifique soit suffisant pour compiler une application complète compatible JAX-RS.

Par exemple, si nous avons un de ces pots API spec sur le chemin de classe, nous pouvons créer une application JAX-RS entière et la compiler, mais pour l'exécuter, si nous n'avons pas l'implémentation réelle, nous devons déployer à un serveur qui a l'implémentation réelle de cette version de spécification, par exemple JBoss ou Glassfish

  • jaxrs-api - Il s'agit de RESTeasy emballage de la spécification. Ce n'est pas le pot de spécifications officiel, mais il respecte les contrats de spécifications. RESTeasy utilise ce pot pour toute la ligne de spécifications, c'est-à-dire 1.x - courant. Bien que le pot change les internes pour adhérer aux différentes versions de JAX-RS.

  • jsr311-api - Ceci est le pot de spécifications officiel pour la ligne JAX-RS 1.x.

  • javax.ws.rs-api - Il s'agit du fichier de spécifications officiel de la ligne JAX-RS 2.x.

  • jersey-core - Ceci est une implémentation partielle de la spécification. Le reste de l'implémentation est contenu dans d'autres pots Jersey. Notez que dans les versions antérieures de Jersey, ils comprenaient en fait les API de spécification JAX-RS dans ce pot. Ce n'est que plus tard que Jersey a commencé à utiliser les pots officiels.

  • jaxrs-ri - Ceci est l'implémentation complète de Jersey 2.x emballée dans un bocal. Le "ri" signifie implémentation de référence, ce qui est Jersey: l'implémentation de référence JAX-RS. Si vous n'utilisez pas de gestionnaire de dépendances comme Maven, vous souhaiterez peut-être simplement utiliser ce seul pot au lieu d'avoir à utiliser tous les pots séparés fournis avec Jersey.

Autres ressources

Notez également que bien que différentes implémentations adhèrent à la spécification, chaque implémentation possède son propre ensemble de fonctionnalités supplémentaires. Pour en savoir plus, vous devez parcourir la documentation des différentes implémentations. Les trois implémentations les plus populaires sont Jersey , RESTeasy et CXF

43
Paul Samsotha