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

J'ai googlé un peu je suis encore confus quant à ce que chacun de ce qui précède signifie exactement.

Voici ma compréhension de cela:

  • jaxrs-api : contient uniquement de l'api. Pas de mise en œuvre. Mais en quoi est-ce différent de JSR311
  • jsr311-api: JSR311 c'est une demande de spécification. Ce qui signifie que c'est censé être un document. Pourquoi alors est-il un bocal?
  • javax. ws. rs-api : Est-ce un la mise en œuvre?
  • 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 contient, mais je ne peux trouver que des interfaces dans chacun d'eux et pas l'implémentation.

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

Author: Paul Samsotha, 2015-08-20
Source

1 answers

Je vais d'abord arriver à la question

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

Sauf le dernier (jersey-core), tous ces pots sont des pots "spécification". Les spécifications JAX-RS (ainsi que de nombreuses autres spécifications 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 jar comme contrat. 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 jar de l'API spec soit suffisant pour compiler une application complète compatible JAX-RS.

Par exemple, si nous avons l'un de ces jars API spec sur le classpath, 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 sur un serveur qui a l'implémentation réelle de cette version de spécification, par exemple JBoss ou Glassfish

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

  • Jsr311-api - C'est l'officiel pot de spécifications pour le JAX-RS 1.ligne x.

  • Javax. ws. rs-api - Ceci est le pot de spécifications officiel pour le JAX-RS 2.ligne x.

  • Jersey-core - Ceci est une implémentation partielle de la spécification. Le reste de la mise en œuvre est contenu dans d'autres pots Jersey. Notez que dans les versions antérieures de Jersey, ils ont en fait empaqueté les API JAX-RS spec dans ce pot. Ce n'est que plus tard que Jersey a commencé à utiliser les spécifications officielles pot.

  • Jaxrs-ri - C'est le maillot complet 2.x implémentation empaquetée dans un pot. Le" ri " signifie implémentation de référence, qui est ce que Jersey est: l'implémentation de référence JAX-RS. Si vous n'utilisez pas un gestionnaire de dépendances comme Maven, vous voudrez peut-être simplement utiliser ce seul pot au lieu d'avoir à utiliser tous les pots séparés fournis par Jersey.

D'Autres Ressources

Notez également que bien que différentes implémentations adhèrent à la spécification, chaque implémentation a son propre ensemble de fonctionnalités supplémentaires. Pour en savoir plus, vous devez passer par la documentation des différentes implémentations. Les trois implémentations les plus populaires sont Jersey, Il s'agit de la première version de la série.]}

 35
Author: Paul Samsotha, 2018-09-30 23:01:45