LCC 263 - Le maillot jaune du salon

[Jérémie Bresson]

Deux A et un E discutent des nouvelles de l’été et de la rentrée. #JDK17 #scala #Kotlin #spring6 #dockerdesktop #fitdesk et encore d’autres sujets.

Enregistré le 10 septembre 2022

https://lescastcodeurs.com/2021/09/17/lcc-263-le-maillot-jaune-du-salon/

[Arnaud Héritier]

Merci Jérémie,

Je ne sais plus si l'email est censé être envoyé automatiquement ou si c'est @Emmanuel Bernard qui a buggé ...

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/83db3a0f-a91a-4c85-84ff-e79b7f9ac409n%40googlegroups.com.

--

Arnaud Héritier

Twitter/GitHub/... : aheritier

[Jérémie Bresson]

 A propos de Gradle "Implementation" vs "Api" :

C'est une question de visibilité à la compilation des dépendances transitives.

Donc ça n'est intéressant que quand on écrit une librairie et c'est du point de vue des consommateurs.

J'avais dessiné ces schémas pour comprendre:

https://j2r2b.github.io/2019/09/18/gradle-dependency-types.html

Il faut plusieurs niveau de dépendances et il faut réfléchir "compile time classpath" et "runtime classpath"

L'example qui est souvent donné:

Une librairie utilise StringUtils de apache commons lang. C'est seulement au niveau du code, aucun type n'est exposé dans les signatures de méthodes ou dans la hiérarchie des types. Si la dépendance est déclarée en "compile" (maven) ou "api" (gradle), un consommateur de cette librairie va pouvoir utiliser apache commons lang dans son propre code. Mais dans ce cas, il utilise une dépendance de manière implicite. C'est mauvais car le jour où la libraire change son implementation et remplace apache commons par guava, le code des consommateurs va être cassé.

Alors que si la librairie déclare sa dépendance en "implementation", les consommateurs ne verront cette dépendance au compile time et ne pourront pas l'utiliser.

Au runtime toutes les dépendances sont incluses de toute façon.

Contrairement à ce qui a été dit même avec une dépendance de type "implementation", le consommateur ne va pas pouvoir échanger EclipseLink et Hibernate. Ca c'est plus un pattern de serveur d'application. Dans ce cas il faut que le code écrit n'est aucune référence vers les implementations.

Du coup "compileOnly" et "compileOnlyApi" c'est la même chose, mais pour les libs qui ne seront pas présentes au runtime dans tous les cas.

* "compileOnly" n'est pas du tout visible à la compilation des consommateurs.

* "compileOnlyApi" défini les libs présentes à la compilation et présentes à la compilation pour les consommateurs

C'est très pointu, mais au final un très bon modèle.