LCC 263 - Le maillot jaune du salon

18 views
Skip to first unread message

Jérémie Bresson

unread,
Sep 20, 2021, 4:16:33 AMSep 20
to lescastcodeurs

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

Arnaud Héritier

unread,
Sep 20, 2021, 4:23:19 AMSep 20
to lescast...@googlegroups.com, Emmanuel Bernard
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

unread,
Sep 21, 2021, 12:13:58 AMSep 21
to lescastcodeurs
 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:
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.
Reply all
Reply to author
Forward
0 new messages