DEV Community: Hoani CROSS

Changer son environnement fullstack en un clin d'oeil : partie 2 avec Maven

Hoani CROSS — Sun, 12 Feb 2023 23:16:44 +0000

Vous êtes développeur consultant et vous travaillez pour plusieurs clients ? Vous travaillez aussi sur des projets Open Source ?

Vous avez certainement été confronté au problème de changement de contexte lorsque vous devez passer d'un projet à un autre : changement de version de Java, de Node.js, de configuration Git ou de signature GnuPG...

J'ai commencé une série d'articles sur ce sujet avec un premier article au sujet du changement de version de Java.

Je continue ici cette série et j'aimerais aborder la capacité de Maven à changer de contexte de développement.

Ma façon préférée d'installer Maven

Pour installer Maven, vous pouvez le faire de multiples façons... Passer par le gestionnaire de paquets de votre distribution Linux, utiliser brew sur MacOS, utiliser Chocolatey sous Windows, voire télécharger directement le Zip du projet.

Me concernant, je préfère utiliser l'outil dont je vous ai parlé dans mon premier article : SDKMan !

Avec SDKMan, pour installer Maven, rien de plus simple, il suffit de taper la commande suivante dans votre terminal :

~❯ sdk install maven
Downloading: maven 3.9.0
In progress...
########################################################################## 100,0%
Installing: maven 3.9.0
Done installing!
Do you want maven 3.9.0 to be set as default? (Y/n): 
Setting maven 3.9.0 as default.

Durant l'installation, SDKMan vous demandera si vous désirez définir la version de Maven téléchargée comme étant le version à utiliser par défaut. Vous pourrez répondre par l'affirmative en appuyant simplement sur la touche 'Entrée'.

On pourra vérifier la bonne installation de Maven à l'aide de la commande suivante :

~❯ mvn -version
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /Users/hoanicross/.sdkman/candidates/maven/current
Java version: 19.0.2, vendor: Oracle Corporation, runtime: /Users/hoanicross/.sdkman/candidates/java/19.0.2-open
Default locale: fr_FR, platform encoding: UTF-8
OS name: "mac os x", version: "13.2", arch: "aarch64", family: "mac"

Comme vous pouvez le remarquer, j'utilise un Mac avec une puce ARM d'Apple 😊, en l'occurrence il s'agit d'un Macbook Air M2 !

Comment Maven gère les environnements de développement

Maven intègre en son sein un moyen assez efficace de gérer les différents environnements de développement avec les profils !

Il peuvent s'activer de diverses manières : présence d'une variable d'environnement, détection du type de l'OS ou encore présence d'un fichier...

Cependant, en y regardant de plus près, on remarque que les profils ont surtout été créés pour gérer les différents environnements d'exécution (dev, prod ou preprod par exemple) mais pas vraiment les environnements de développement.

Typiquement, ce qu'on va chercher à changer dans le fichier de configuration de Maven pour passer d'un contexte de développement à un autre, c'est :

l'éventuel proxy utilisé dans votre mission
l'éventuel mirroir utilisé dans votre mission

Ces deux parties sont configurables sous la forme d'un élément respectivement <proxy> ou <mirror> que l'on retrouvera dans des éléments <proxies> ou <mirrors> juste sous l'élément racine <settings> du fichier settings.xml de Maven.

En l'occurrence, dans la mission où je travaille à l'heure où j'écris ces lignes, nous devons utiliser un référentiel interne mirroir de tous les référentiels Maven.

Dans le fichier settings.xml, cela se présente de la façon suivante :

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
          
    <!-- Miroir pour la gestion des dépendances-->
    <mirrors>
        <mirror>
            <id>nexus</id>
            <mirrorOf>*</mirrorOf>
            <url>https://nexus.domaine-interne-de-mon-client.com/repo/maven/</url>
        </mirror>
    </mirrors>
    
</settings>

Dès qu'une dépendance doit être téléchargée de quelque référentiel Maven que ce soit, c'est le serveur Nexus de mon client qui sera interrogé via l'URL https://nexus.domaine-interne-de-mon-client.com/repo/maven/ qui n'est accessible QUE lorsque le VPN est activé...

Clairement, si je ne suis plus connecté au VPN du client et que je souhaite travailler sur un projet Java open source perso avec Maven, ça ne va plus marcher : les dépendances vont être téléchargées depuis le Nexus qui est indisponible (le VPN n'est pas monté) et la construction va échouer.

Pour continuer à travailler sur ce projet, il me faudrait éditer le fichier ~/.m2/settings.xml, et mettre en commentaire le bloc <mirrors>...</mirrors> à chaque fois...

Et la même opération devra être réalisée lorsque je devrais à nouveau travailler sur un projet de mon client.

Une vraie purge ☹️

Il me fallait donc absolument trouver une solution pour que cette bascule se fasse automatiquement !

Comment ChatGPT m'a mis sur la voie

Dans cette quête de pouvoir obtenir mon mécanisme de changement de contexte de développement, je me suis dit que ChatGPT pouvait peut-être m'aider.

Voici la requête que je lui ai soumis :

Hello, I would like to activate the ability of maven settings to setup a local repository to be the mirror of all existing repository, especially the public ones, only when I am connected to their network. For all other situation, I want this mirroring property to be deactivated. Do you have a solution for my problem ?

Ici, je lui ai demandé de pouvoir activer automatiquement la notion de référentiel local en tant que mirroir de toutes les autres, seulement lorsque je suis connecté au réseau du client.

Dans sa réponse, il fait justement référence à la notion de profil dont je vous ai parlé précédemment :

Yes, you can configure your Maven settings to mirror remote repositories when you are connected to a specific network, and to not mirror them when you are not connected to that network. To do this, you will need to create two separate profiles in your settings.xml file: one for the scenario where you are connected to the network, and one for when you are not.

In the profile for when you are connected to the network, you can specify a mirror that points to the local repository, and include a <mirrorOf>*</mirrorOf> element to indicate that all remote repositories should be mirrored to the local repository.

In the profile for when you are not connected to the network, you can remove the mirror from the profile, and instead include the remote repositories that you want to use directly in the <repositories> element.

You can use <activeByDefault> and <activation> elements to specify which profile is active depending on your network state.

It is important to note that, if you want to use this feature, you need to have a local repository already configured, and you should consider the amount of space that the repository will need.

Ah mais c'est super ça 😃 ! Je vais donc pouvoir utiliser les profils pour activer ou non les mirroirs des référentiel Maven... Il fallait que j'en sache plus et j'ai donc demandé à ChatGPT :

Can you provide me an example of a settings.xml maven file that implements those needs ?

Et voici le fichier exemple qu'il m'a fournit :

<settings>
    <mirrors>
        <mirror>
            <id>mirror-local-repo</id>
            <mirrorOf>*</mirrorOf>
            <url>file:///path/to/local/repo</url>
        </mirror>
    </mirrors>

    <profiles>
        <profile>
            <id>on-corporate-network</id>
            <activation>
                <property>
                    <name>onCorporateNetwork</name>
                    <value>true</value>
                </property>
            </activation>
            <repositories>
                <repository>
                    <id>central</id>
                    <url>http://central</url>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </releases>
                </repository>
            </repositories>
        </profile>
        <profile>
            <id>off-corporate-network</id>
            <activation>
                <property>
                    <name>onCorporateNetwork</name>
                    <value>false</value>
                </property>
            </activation>
            <repositories>
                <repository>
                    <id>central</id>
                    <url>http://central</url>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </releases>
                </repository>
                <repository>
                    <id>other-repo</id>
                    <url>http://other-repo</url>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </releases>
                </repository>
            </repositories>
        </profile>
    </profiles>
</settings>

Euuuh 🧐 le bloc <proxies> n'est pas inclus où même associé à la partie concernant les différents profils et je m'empresse d'en faire mention à ChatGTP :

However, in the example you provided, the mirror functionnality will be activated for both profiles since it is not part of the definition of the <profile> element. I really want the mirror to be deactivated when the off-corporate-network is active.

Et admirez ce que ChatGPT me propose comme fichier settings.xml :

<settings>
    <profiles>
        <profile>
            <id>on-corporate-network</id>
            <activation>
                <property>
                    <name>onCorporateNetwork</name>
                    <value>true</value>
                </property>
            </activation>
            <mirrors>
                <mirror>
                    <id>mirror-local-repo</id>
                    <mirrorOf>*</mirrorOf>
                    <url>file:///path/to/local/repo</url>
                </mirror>
            </mirrors>
            <repositories>
                <repository>
                    <id>central</id>
                    <url>http://central</url>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </releases>
                </repository>
            </repositories>
        </profile>
        <profile>
            <id>off-corporate-network</id>
            <activation>
                <property>
                    <name>onCorporateNetwork</name>
                    <value>false</value>
                </property>
            </activation>
            <repositories>
                <repository>
                    <id>central</id>
                    <url>http://central</url>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </releases>
                </repository>
                <repository>
                    <id>other-repo</id>
                    <url>http://other-repo</url>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </releases>
                </repository>
            </repositories>
        </profile>
    </profiles>
</settings>

Eh bien voilà ! C'était tellement simple... Mais je voulais quand même en avoir le coeur net car la documentation de Maven ne mentionne pas du tout cette possibilité.

Voici ce que j'ai dit à ChatGPT :

Reading the version 1.0.0 of the Maven settings XSD, the <profile> element can only contain direct child elements of type <id>, <activation>, <repositories>, <pluginRepositories> or <properties>. It cannot contain a <mirrors> child element.

Et vous savez quoi ? Il a admi son erreur et il est revenu sur sa première proposition qui ne permettait pas de conditionner l'activation des mirroirs selon les profils... On se marche sur la tête 🤨

C'est alors que je me suis dit que si le fonctionnement interne de Maven ne permettait pas d'activer ou non dynamiquement la notion de mirroir, il se pourrait qu'un outil externe puisse le faire à la place de Maven.

J'ai commencé à rédiger ma requête pour ChatGPT quand je me suis dit : "je peux le faire moi-même, sans l'aide de ChatGPT".

Ainsi, en me faisant tourner en bourrique, ChatGPT m'a ouvert sur une possibilité externe à Maven : jongler avec plusieurs fichiers de configuration !

Avoir plusieurs fichiers de configuration

Par défaut, Maven va chercher sa configuration dans :

le fichier pom.xml du projet courant
le fichier ~/.m2/settings.xml
le fichier conf/settings.xml du répertoire d'installation de Maven

Cela ne laisse pas beaucoup de place pour insérer quelque chose...

Si on tape mvn --help dans un terminal, on peut lire cette option de maven :

 -s,--settings <arg>                    Alternate path for the user
                                        settings file

C'est exactement ce dont j'avais besoin !

Lorsque je travaille sur un projet d'un client, on va dire lambda, je veux utiliser le fichier de configuration ~/.m2/settings-lambda.xml.

Pour les autres projets Open Source perso, le fichier ~/.m2/settings.xml d'origine fera très bien l'affaire !

Pour un projet Open Source sur lequel je travail, je peux utiliser la commande mvn comme à l'accoutumée.

Pour un projet de mon client lambda, par contre, je vais donc devoir faire :

~❯ mvn -s ~/.m2/settings-lambda.xml clean install

Bon on va dire que c'est mieux que d'éditer le fichier settings.xml de Maven mais ça ne me convient toujours pas ! Moi ce que j'aimerais c'est de trouver un moyen de configurer ça automatiquement pour toute une arborescence !

Un wrapper magique pour `mvn`

Ma solution idéale voudrait que j'ai juste à utiliser la commande mvn comme j'ai l'habitude de le faire et que le fichier de configuration spécifique soit ajouté à la commande à l'aide de l'option -s, uniquement quand c'est nécessaire.

Dans mon cas, je veux que ça soit activé lorsque je suis dans mon répertoire parent de tous les projets de mon client lambda, à savoir ~/devel/lambda.

Retrouver le nom du fichier de configuration spécifique

Par convention, j'ai donc décidé de dire que lorsqu'un fichier nommé .m2_settings était trouvé dans le répertoire courant ou dans un de ses répertoires parents, son contenu sera lu et considédé comme le chemin d'un fichier de configuration spécifique à prendre en compte au lancement de la commande mvn.

En simple langage shell, j'en suis arrivé au code suivant pour obtenir le contenu de ce fameux fichier .m2_settings :

# Find the given file going up in the parent directories
# until found, return "" either
find_up() {
  pth=$(pwd)
  while [[ "$pth" != "" && ! -e "$pth/$1" ]]; do
    pth=${pth%/*}
  done
  echo "$pth"
} 

M2_SETTINGS_CONFIG_NAME=.m2_settings

check_mvn_settings() {
  MVN_SETTINGS=~/.m2/settings.xml
  fnd_dir=$(find_up $M2_SETTINGS_CONFIG_NAME)
  if [[ "" != "$fnd_dir" ]]; then
    MVN_SETTINGS=$(cat $fnd_dir/$M2_SETTINGS_CONFIG_NAME)
  fi
  echo "${MVN_SETTINGS/#\~/$HOME}"
}

La fonction find_up() trouve un fichier dont le nom est passé en paramètres dans le répertoire courant et ses répertoires parents jusqu'à ce qu'il soit trouvé, et dans le cas où ce fichier serait introuvable, une chaîne vide sera retournée.

La fonction check_mvn_settings() retournera :

le nom du fichier de configuration sécifique trouvé dans le fichier .m2_settings s'il est trouvé
$HOME/.m2/settings.xml sinon

Notez que l'expression ${MVN_SETTINGS/#\~/$HOME} permet de remplacer toute occurence de ~ par $HOME dans la variable d'environnement MVN_SETTINGS avant de la retourner car sans cela ça générait des problèmes d'interprétation.

Trouver le binaire `mvn` d'origine

Mon wrapper sera intitulé mvn comme la commande d'origine. Je ne veux pas changer mes habitudes.

Le chemin vers ce dernier sera d'ailleurs prioritaire au chemin du binaire mvn d'origine pour qu'il puisse faire cette action magique d'ajout automatique du fichier de configuration spécifique...

Seulement voilà : je ne voulais pas avoir à préciser dans ce dernier l'emplacement du binaire de Maven d'origine.

Je voulais que mon script le trouve tout seul.

Voici le bout de code shell qui réalise cette opération :

get_mvn_bin() {
  directory_to_remove=$(cd $(dirname $0) && pwd)
  PATH=:$PATH:
  PATH=${PATH//:$directory_to_remove:/:}
  PATH=${PATH#:}; PATH=${PATH%:}
  echo $(whereis mvn | awk '{print$2}')
}

Je sais, c'est magique. Et en plus ça marche 😝

Pour résumer le fonctionnement de ce code, ce dernier :

récupère le répertoire du wrapper
retire ce répertoire de la variable d'environnement PATH
appelle la commande whereis pour trouver le chemin de la commande mvn d'origine (le wrapper n'étant plus trouvable ici)
retourne ce chemin à l'appelant

Le corps principal du wrapper

Il ne reste plus qu'a appeler toutes ces fonctions et gérer le cas où Maven n'est pas trouvé :

MVN_CMD=$(get_mvn_bin)
if [[ "" == "$MVN_CMD" ]]; then
  >&2 echo "mvn command not found in PATH variable !"
  exit -1
fi
MVN_SETTINGS=$(check_mvn_settings)
$MVN_CMD -s $MVN_SETTINGS $@

Et voilà !

Le script complet

Voici le code du script complet :

#!/bin/sh

# Find the given file going up in the parent directories
# until found, return "" either
find_up() {
  pth=$(pwd)
  while [[ "$pth" != "" && ! -e "$pth/$1" ]]; do
    pth=${pth%/*}
  done
  echo "$pth"
} 

M2_SETTINGS_CONFIG_NAME=.m2_settings

check_mvn_settings() {
  MVN_SETTINGS=~/.m2/settings.xml
  fnd_dir=$(find_up $M2_SETTINGS_CONFIG_NAME)
  if [[ "" != "$fnd_dir" ]]; then
    MVN_SETTINGS=$(cat $fnd_dir/$M2_SETTINGS_CONFIG_NAME)
  fi
  echo "${MVN_SETTINGS/#\~/$HOME}"
}

get_mvn_bin() {
  directory_to_remove=$(cd $(dirname $0) && pwd)
  PATH=:$PATH:
  PATH=${PATH//:$directory_to_remove:/:}
  PATH=${PATH#:}; PATH=${PATH%:}
  echo $(whereis mvn | awk '{print$2}')
}

MVN_CMD=$(get_mvn_bin)
if [[ "" == "$MVN_CMD" ]]; then
  >&2 echo "mvn command not found in PATH variable !"
  exit -1
fi
MVN_SETTINGS=$(check_mvn_settings)
$MVN_CMD -s $MVN_SETTINGS $@

Faire un wrapper vraiment complet

Rediriger la commande mvn ne me semblait pas suffisant.

En effet, je voulais notamment que cette commande se retrouve dans un répertoire dont la structure est identique à celle d'une installation de Maven classique.

J'ai opté pour la convention suivante :

le répertoire d'installation de mon wrapper sera ~/.wrapper/maven
tout sont contenu sera un lien symbolique du répertoire d'installation de la version courante de Maven dans le répertoire de SDKMan
à l'exception du répertoire bin qui contiendra mon wrapper magique et des liens symboliques vers les autres binaires

Voilà ce que ça donne :

~❯ ls -lah .wrapper/maven
total 0
drwxr-xr-x  9 hoanicross  staff   288B 26 jan 08:07 .
drwxr-xr-x  3 hoanicross  staff    96B 26 jan 08:04 ..
lrwxr-xr-x  1 hoanicross  staff    58B 26 jan 08:06 LICENSE -> /Users/hoanicross/.sdkman/candidates/maven/current/LICENSE
lrwxr-xr-x  1 hoanicross  staff    57B 26 jan 08:06 NOTICE -> /Users/hoanicross/.sdkman/candidates/maven/current/NOTICE
lrwxr-xr-x  1 hoanicross  staff    61B 26 jan 08:07 README.txt -> /Users/hoanicross/.sdkman/candidates/maven/current/README.txt
drwxr-xr-x  8 hoanicross  staff   256B 12 fév 23:33 bin
lrwxr-xr-x  1 hoanicross  staff    55B 26 jan 08:06 boot -> /Users/hoanicross/.sdkman/candidates/maven/current/boot
lrwxr-xr-x  1 hoanicross  staff    55B 26 jan 08:06 conf -> /Users/hoanicross/.sdkman/candidates/maven/current/conf
lrwxr-xr-x  1 hoanicross  staff    54B 26 jan 08:06 lib -> /Users/hoanicross/.sdkman/candidates/maven/current/lib

~❯ ls -lah .wrapper/maven/bin
total 8
drwxr-xr-x  8 hoanicross  staff   256B 12 fév 23:33 .
drwxr-xr-x  9 hoanicross  staff   288B 26 jan 08:07 ..
lrwxr-xr-x  1 hoanicross  staff    62B 26 jan 08:08 m2.conf -> /Users/hoanicross/.sdkman/candidates/maven/current/bin/m2.conf
-rwxr-xr-x@ 1 hoanicross  staff   876B  6 fév 11:14 mvn
lrwxr-xr-x  1 hoanicross  staff    62B 26 jan 08:07 mvn.cmd -> /Users/hoanicross/.sdkman/candidates/maven/current/bin/mvn.cmd
lrwxr-xr-x  1 hoanicross  staff    63B 26 jan 08:07 mvnDebug -> /Users/hoanicross/.sdkman/candidates/maven/current/bin/mvnDebug
lrwxr-xr-x  1 hoanicross  staff    67B 26 jan 08:08 mvnDebug.cmd -> /Users/hoanicross/.sdkman/candidates/maven/current/bin/mvnDebug.cmd
lrwxr-xr-x  1 hoanicross  staff    61B 26 jan 08:08 mvnyjp -> /Users/hoanicross/.sdkman/candidates/maven/current/bin/mvnyjp

Comme vous pouvez le voir, j'ai donc utilisé la commande ln -s à outrance pour arriver à mes fins !

Rendre le wrapper disponible dans la variable d'environnement `PATH`

Il ne reste plus maintenant qu'à rendre ce merveilleux wrapper disponible dans la variable d'environnement PATH en priorité.

On pourra notamment créer une variable d'environnement MAVEN_HOME pointant vers le répertoire d'installation du wrapper et on ajoutera $MAVEN_HOME/bin au tout début de la variable d'environnement PATH.

Cela pourra notamment être rendu possible en ajoutant les lignes suivantes à la fin de votre script d'initialisation de votre interpréteur de commande (~/.bashrc si vous utilisez bash ou ~/.zshrc si vous utilisez zsh) :

export MAVEN_HOME=~/.wrapper/maven
export PATH=$MAVEN_HOME/bin;$PATH

Relancez votre terminal et vous voilà paré pour changer d'environnement de développement à la volée avec Maven 🤤 en utilisant la commande mvn comme à l'accoutumée...

Limite de ce procédé dans les IDE

Ce wrapper est surtout magique en ligne de commande.

Dans votre IDE, cela ne marchera pas de façon transparente.

J'ai notamment pu constater que dans IntelliJ IDEA, étant donné que ce dernier utilise une installation de Maven embarquée par défaut, le changement de fichier de configuration ne se fait pas automatiquement.

Néanmoins, il reste possible de configurer le fichier de configuration à prendre en considération pour le projet en cours, ce qui nécessite une manipulation à faire une seule fois pour chaque projet. Pour moi cette contrainte est largement acceptable !

J'en profite aussi pour définir, dans le champ consacré à cet effet, le répertoire d'installation de Maven comme étant le répertoire d'installation de mon wrapper.

Et la suite ?

Dans mon prochain article, je vous expliquerais comment j'ai réussi à jongler avec mes identités et signatures Git en fonction des projets sur lesquels je travaile !

Si vous voulez savoir quand je sortirais un nouvel article, suivez-moi sur LinkedIn ou Dev.to !

J'aimerais aussi terminer en vous expliquant rapidement qui je suis 😄

Je m'appelle Hoani CROSS. Je suis originaire de Polynésie Française.

Passionné d'informatique depuis toujours (j'ai commencé à développer en CP, il y a environ 40 ans), j'ai évolué dans beaucoup d'environnements et occupé de nombreux poste, jusqu'à celui de DSI...

Aujourd'hui je suis manager et backend architect chez SFEIR, une Néo-ESN française. Une des particularités de SFEIR, c'est que les managers sont également des exécutants en mission chez des clients. On comprends ce que font les employés qu'on manage et croyez-moi, ça fait une sacré différence ! Et enfin, ce qui nous relie tous chez SFEIR, c'est la passion pour l'informatique... Étant donné qu'elle me suit depuis 40 ans, autant vous dire que je suis tombé au bon endroit !..

D'ailleurs, si vous êtes passionné comme moi, il y certainement une mission de rêve qui vous attends chez SFEIR alors n'hésitez pas à me contacter si vous voulez changer d'horizon.

Enfin, je suis aussi le propriétaire du blog Geek & Rentable, que je vous invite à aller découvrir.

Dans ce blog, je souhaite accompagner les développeurs/développeuses ou autre acteurs/actrices de la tech, passionné.e.s mais malheureusement incompris.es, de manière à ce qu'ils ou elles puissent évoluer vers de bien meilleurs conditions de travail.

À très bientôt.

Illustration par Ang3llor3 sur DeviantArt

Changer son environnement fullstack en un clin d'oeil : partie 1 avec Java

Hoani CROSS — Sun, 05 Feb 2023 08:44:15 +0000

Vous êtes un développeur consultant. Vous travaillez pour plusieurs clients. Ou tout simplement, vous travaillez à la fois pour votre employeur et pour un ou plusieurs projets open source, durant votre temps libre.

Lorsque vous passez d'un projet de développement à un autre, vous avez certainement dû changer tous vos outils et identifiants...

Changement de votre identifiant Git, de votre signature GnuPG, de vos clés SSH... Sans parler des versions des outils que vous utilisez : version de Java, de NodeJS ou de Python.

Il y a même les configurations des outils de constructions qui doivent changer comme celles de Maven ou de NPM.

Pas simple pour passer d'un contexte à l'autre.

Bonne nouvelle : j'ai déjà expérimenté plusieurs solutions pour répondre à ces besoins et je voudrais partager avec vous le résultat de mes recherches !

Je vous propose d'aborder cela sous la forme de plusieurs petits articles ciblés sur chaque astuce trouvée.

Gérer vos versions de Java

Commençons par aborder le fait de devoir gérer plusieurs versions de Java.

Attention on ne prendra pas en compte les versions de Java antérieures à la version 8.

Si vous êtes sous Linux Debian ou un de ses dérivés (notamment Ubuntu), il existe des outils assez pratiques répondant à la problématique comme update-alternatives voire update-java-alternatives. Néanmoins, ces solutions se cantonent à un seul système et je voulais dans mes recherches trouver un outil cross-platform.

En fait il existe pas mal d'outils pour gérer ses différentes versions de Java : jEnv ou encore Jabba. Pour ma part, j'ai souhaité me concentrer sur un outil plutôt plébicité pour ce besoin : SDKMan.

SDKMan est un logiciel open source sous licence Apache 2.0. C'est un projet très actif sur GitHub. Il est également possible de soutenir le projet financièrement via le site Open Collective.

SDKMan est centré sur la gestion des différentes versions de Java mais aussi des outils et autres technologies liées.

On pourra aussi gérer ses différentes version de Maven ou de Kotlin avec SDKMan (ce que je fais à titre personnel).

Installer SDKMan

Pour utiliser SDKMan, vous devez disposer d'un système Linux, Windows (via WSL) ou MacOS. Il est également possible de l'installer sur FreeBSD voire Solaris !

SDKMan étant un outil en ligne de commande, il a besoin d'interagir avec votre interpréteur de ligne de commande préféré. En l'occurrence, il gère Bash et Zsh.

Pour installer SDKMan, ouvrez un terminal et tapez la commande suivante :

curl -s "https://get.sdkman.io" | bash

Petit disclaimer sur ce type d'installation quand même, je vous invite à télécharger et à consulter le contenu de https://get.sdkman.io pour savoir ce que fait le script avant de confier ça à bash aveuglément ! Vous êtes prévenus 😄

En fonction de l'interpréteur de ligne de commande que vous utilisez, votre fichier .bashrc ou .zshrc sera modifié en conséquence pour ajouter la commande sdk de SDKMan.

Notez aussi que SDKMan va créer un répertoire .sdkman à la racine de votre répertoire utilisateur dans lequel on retrouvera non seulement l'outil sdk mais aussi toutes les installations de Java, Maven ou Kotlin.

Téléchargez votre version de Java par défaut

Maintenant que SDKMan est installé, on va l'utiliser pour installer votre version de Java par défaut.

Pour obtenir la liste des versions de Java disponibles avec SDKMan, vous devez taper la commande suivante dans un terminal :

$> sdk list java

SDKMan pour fournira une liste des distributions disponibles pour votre architecture matérielle (vous pouvez voir les architectures matérielles supportées ici au chapitre Multi-platform binary distributions).

Personnellement j'aime bien prendre la dernière version stable, par forcément LTS, celle d'OpenJDK de Java.net.

À l'heure où sont écrites ces lignes, il s'agit de la version 19.0.2-open.

Si vous voulez installer cette version, il vous suffira de taper la commande suivante dans un terminal :

$> sdk install java 19.0.2-open
Downloading: java 19.0.2-open
In progress...
######################################################################### 100,0%
Repackaging Java 19.0.2-open...
Done repackaging...
Cleaning up residual files...
Installing: java 19.0.2-open
Done installing!
Do you want java 19.0.2-open to be set as default? (Y/n): Y
Setting java 19.0.2-open as default.

Comme illustré ci-dessus, SDKMan vous demandera si vous désirez définir cette nouvelle version téléchargée comme votre version de Java par défaut : répondez Y pour donner votre accord.

Vous pourrez valider que vous avez bien ce que vous désirez avec les commandes suivantes :

$> java -version
openjdk version "19.0.2" 2023-01-17
OpenJDK Runtime Environment (build 19.0.2+7-44)
OpenJDK 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing)

Installer d'autres versions de Java

Bon pour l'instant et d'après ce que je vous ai montré, SDKMan n'apporte rien par rapport à une bonne vieille installation manuelle de Java.

Justement, nous allons maintenant voir le gros avantage de cet outil : la capacité à installer plusieurs versions de Java et à passer d'une version à une autre.

Pour lister la liste des versions de Java disponibles, faites comme dans le chapitre suivant et tapez la commande suivante :

$> sdk list java
================================================================================
Available Java Versions for macOS ARM 64bit
================================================================================
 Vendor        | Use | Version      | Dist    | Status     | Identifier
--------------------------------------------------------------------------------
 Corretto      |     | 19.0.2       | amzn    |            | 19.0.2-amzn         
               |     | 19.0.1       | amzn    |            | 19.0.1-amzn         
               |     | 17.0.6       | amzn    |            | 17.0.6-amzn         
               |     | 17.0.5       | amzn    |            | 17.0.5-amzn         
               |     | 11.0.18      | amzn    |            | 11.0.18-amzn        
               |     | 11.0.17      | amzn    |            | 11.0.17-amzn        
               |     | 8.0.362      | amzn    |            | 8.0.362-amzn        
               |     | 8.0.352      | amzn    |            | 8.0.352-amzn        
 Gluon         |     | 22.1.0.1.r17 | gln     |            | 22.1.0.1.r17-gln    
               |     | 22.1.0.1.r11 | gln     |            | 22.1.0.1.r11-gln    
 GraalVM       |     | 22.3.r19     | grl     |            | 22.3.r19-grl        
               |     | 22.3.r17     | grl     |            | 22.3.r17-grl        
               |     | 22.3.r11     | grl     |            | 22.3.r11-grl        
               |     | 22.3.1.r19   | grl     |            | 22.3.1.r19-grl      
               |     | 22.3.1.r17   | grl     |            | 22.3.1.r17-grl      
               |     | 22.3.1.r11   | grl     |            | 22.3.1.r11-grl      
               |     | 22.2.r17     | grl     |            | 22.2.r17-grl        
               |     | 22.2.r11     | grl     |            | 22.2.r11-grl        
               |     | 22.1.0.r17   | grl     |            | 22.1.0.r17-grl      
               |     | 22.1.0.r11   | grl     |            | 22.1.0.r11-grl      
 Java.net      |     | 21.ea.8      | open    |            | 21.ea.8-open        
               |     | 21.ea.7      | open    |            | 21.ea.7-open        
               |     | 21.ea.6      | open    |            | 21.ea.6-open        
               |     | 21.ea.5      | open    |            | 21.ea.5-open        
               |     | 21.ea.4      | open    |            | 21.ea.4-open        
               |     | 20.ea.34     | open    |            | 20.ea.34-open       
               |     | 20.ea.33     | open    |            | 20.ea.33-open       
               |     | 20.ea.32     | open    |            | 20.ea.32-open       
               |     | 20.ea.31     | open    |            | 20.ea.31-open       
               |     | 20.ea.30     | open    |            | 20.ea.30-open       
               | >>> | 19.0.2       | open    | installed  | 19.0.2-open         
               |     | 19.0.1       | open    |            | 19.0.1-open         
 Liberica      |     | 19.0.2.fx    | librca  |            | 19.0.2.fx-librca    
               |     | 19.0.2       | librca  |            | 19.0.2-librca       
               |     | 19.0.1.fx    | librca  |            | 19.0.1.fx-librca    
               |     | 19.0.1       | librca  |            | 19.0.1-librca       
               |     | 17.0.6.fx    | librca  |            | 17.0.6.fx-librca    
               |     | 17.0.6       | librca  |            | 17.0.6-librca       
               |     | 17.0.5.fx    | librca  |            | 17.0.5.fx-librca    
               |     | 17.0.5       | librca  |            | 17.0.5-librca       
               |     | 11.0.18.fx   | librca  |            | 11.0.18.fx-librca   
               |     | 11.0.18      | librca  |            | 11.0.18-librca      
               |     | 11.0.17.fx   | librca  |            | 11.0.17.fx-librca   
               |     | 11.0.17      | librca  |            | 11.0.17-librca      
               |     | 8.0.362.fx   | librca  |            | 8.0.362.fx-librca   
               |     | 8.0.362      | librca  |            | 8.0.362-librca      
               |     | 8.0.352.fx   | librca  |            | 8.0.352.fx-librca   
               |     | 8.0.352      | librca  |            | 8.0.352-librca      
 Liberica NIK  |     | 22.3.r17     | nik     |            | 22.3.r17-nik        
               |     | 22.3.r11     | nik     |            | 22.3.r11-nik        
               |     | 22.3.1.r17   | nik     |            | 22.3.1.r17-nik      
               |     | 22.3.1.r11   | nik     |            | 22.3.1.r11-nik      
               |     | 22.2.r17     | nik     |            | 22.2.r17-nik        
               |     | 22.2.r11     | nik     |            | 22.2.r11-nik
 Microsoft     |     | 17.0.6       | ms      |            | 17.0.6-ms           
               |     | 17.0.5       | ms      |            | 17.0.5-ms           
               |     | 11.0.18      | ms      |            | 11.0.18-ms          
               |     | 11.0.17      | ms      |            | 11.0.17-ms          
 Oracle        |     | 19.0.2       | oracle  |            | 19.0.2-oracle       
               |     | 19.0.1       | oracle  |            | 19.0.1-oracle       
               |     | 17.0.6       | oracle  |            | 17.0.6-oracle       
               |     | 17.0.5       | oracle  |            | 17.0.5-oracle       
 SapMachine    |     | 19.0.2       | sapmchn |            | 19.0.2-sapmchn      
               |     | 19.0.1       | sapmchn |            | 19.0.1-sapmchn      
               |     | 17.0.6       | sapmchn |            | 17.0.6-sapmchn      
               |     | 17.0.5       | sapmchn |            | 17.0.5-sapmchn      
               |     | 11.0.18      | sapmchn |            | 11.0.18-sapmchn     
               |     | 11.0.17      | sapmchn |            | 11.0.17-sapmchn     
 Semeru        |     | 18.0.2       | sem     |            | 18.0.2-sem          
               |     | 17.0.5       | sem     |            | 17.0.5-sem          
               |     | 17.0.4.1     | sem     |            | 17.0.4.1-sem        
               |     | 11.0.17      | sem     |            | 11.0.17-sem         
               |     | 11.0.16.1    | sem     |            | 11.0.16.1-sem       
 Temurin       |     | 19.0.2       | tem     |            | 19.0.2-tem          
               |     | 19.0.1       | tem     |            | 19.0.1-tem          
               |     | 17.0.6       | tem     |            | 17.0.6-tem          
               |     | 17.0.5       | tem     |            | 17.0.5-tem          
               |     | 11.0.18      | tem     |            | 11.0.18-tem         
               |     | 11.0.17      | tem     |            | 11.0.17-tem         
 Zulu          |     | 19.0.2       | zulu    |            | 19.0.2-zulu         
               |     | 19.0.2.fx    | zulu    |            | 19.0.2.fx-zulu      
               |     | 19.0.1       | zulu    |            | 19.0.1-zulu         
               |     | 19.0.1.fx    | zulu    |            | 19.0.1.fx-zulu      
               |     | 17.0.6       | zulu    |            | 17.0.6-zulu         
               |     | 17.0.6.fx    | zulu    |            | 17.0.6.fx-zulu      
               |     | 17.0.5       | zulu    |            | 17.0.5-zulu         
               |     | 17.0.5.fx    | zulu    |            | 17.0.5.fx-zulu      
               |     | 11.0.18      | zulu    |            | 11.0.18-zulu        
               |     | 11.0.18.fx   | zulu    |            | 11.0.18.fx-zulu     
               |     | 11.0.17      | zulu    |            | 11.0.17-zulu        
               |     | 11.0.17.fx   | zulu    |            | 11.0.17.fx-zulu     
               |     | 8.0.362      | zulu    |            | 8.0.362-zulu        
               |     | 8.0.362.fx   | zulu    |            | 8.0.362.fx-zulu     
               |     | 8.0.352      | zulu    |            | 8.0.352-zulu        
               |     | 8.0.352.fx   | zulu    |            | 8.0.352.fx-zulu     
================================================================================
Omit Identifier to install default version 17.0.6-tem:
    $ sdk install java
Use TAB completion to discover available versions
    $ sdk install java [TAB]
Or install a specific version by Identifier:
    $ sdk install java 17.0.6-tem
Hit Q to exit this list view
================================================================================
(END)

Comme vous pouvez éventuellement le remarquer, il s'agit des version disponibles pour l'architecture ARM 64bits de MacOS (j'utilise actuellement un MacBook Air M2)... Et il y en a beaucoup.

Je ne vous ferais pas aujourd'hui un comparatif des différentes déclinaisons de Java selon les différents fournisseurs (ça fera peut-être partie d'un futur article ?) mais de mon côté, j'utilise pour mes versions non bleeding edge, celles de Zulu.

En l'occurrence, ce qui me plait dans les versions de Zulu sont le compilateur JIT Falcon basé sur LLVMet le garbage collector C4.

Chez le client pour lequel je travaille, on retrouve des projets développés pour Java 8, 11 et plus récemment 17.

J'ai donc installé la version 17.0.6-zulu, à l'aide de la commande suivante :

$> sdk install java 17.0.6-zulu
Downloading: java 17.0.6-zulu
In progress...
########################################################################## 100,0%
Repackaging Java 17.0.6-zulu...
Done repackaging...
Installing: java 17.0.6-zulu
Done installing!
Do you want java 17.0.6-zulu to be set as default? (Y/n): n

Et cette fois, contrairement à la première fois, j'ai préféré ne pas changer la version par défaut avec cette version de Java.

La démarche n'est pas très différente pour les versions 11.0.18-zulu et 8.0.362-zulu :

$> sdk install java 11.0.18-zulu
(...)
$> sdk install java 8.0.362-zulu
(...)

Et vous voilà avec les trois dernières versions LTS de Java d'installées sur votre poste !

Passer d'une version de Java à une autre

Pour changer la version en cours de Java, vous devrez utiliser la commande suivante (ici illustrée avec la version 17.0.6-zulu) :

$> sdk use java 17.0.6-zulu

Using java version 17.0.6-zulu in this shell.

Une petite vérification de la version en cours permet de confirmer le bon fonctionnement de l'opération :

$> java -version
openjdk version "17.0.6" 2023-01-17 LTS
OpenJDK Runtime Environment Zulu17.40+19-CA (build 17.0.6+10-LTS)
OpenJDK 64-Bit Server VM Zulu17.40+19-CA (build 17.0.6+10-LTS, mixed mode, sharing)

Changement automatique de la version de Java

Il est possible, à l'aide de SDKMan d'enregistrer la version en cours d'utilisation de Java pour un projet en particulier.

Imaginons que vous avez un projet legacy de votre client qui utilise encore du Java 8.

Pour associer cette version de java avec ledit projet, il vous faudra vous rendre dans ce projet, changer la version de java et lancer la commande sdk env init :

~ $> cd devel/mon_client/projet_java8
~/devel/mon_client/projet_java8 $> sdk use java 8.0.362-zulu
Using java version 8.0.362-zulu in this shell.
~/devel/mon_client/projet_java8 $> sdk env init
.sdkmanrc created.
~/devel/mon_client/projet_java8 $> java -version
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (Zulu 8.68.0.19-CA-macos-aarch64) (build 1.8.0_362-b08)
OpenJDK 64-Bit Server VM (Zulu 8.68.0.19-CA-macos-aarch64) (build 25.362-b08, mixed mode)

Maintenant, avec cette configuration, il suffira de lancer la commande sdk env au sein du répertoire configuré pour que la version correcte de Java soit sélectionnée !

~ $> cd devel/mon_client/projet_java8
~/devel/mon_client/projet_java8 $> sdk env
Using java version 8.0.362-zulu in this shell.

Maintenant encore mieux : il est possible de faire en sorte que la version de Java change automatiquement lorsque vous entrez dans le répertoire dudit projet configuré !

Pour cela, vous allez devoir modifier la configuration de SDKMan en éditant le fichier ~/.sdkman/etc/config et assigner la variable de configuration sdkman_auto_env à true.

Il est possible de le faire en une ligne sur MacOS à l'aide de la commande suivante :

$> sed 's/sdkman_auto_env=false/sdkman_auto_env=true/g' ~/.sdkman/etc/config > /tmp/sdkman-cfg && cat /tmp/sdkman-cfg > ~/.sdkman/etc/config

Sous GNU Linux, c'est plus simple :

$> sed -i 's/sdkman_auto_env=false/sdkman_auto_env=true/g' ~/.sdkman/etc/config

Maintenant, un petit tour dans le répertoire de votre projet en Java 8 et le changement est automatique (attention il faut ouvrir un nouveau terminal pour que ça soit effectif) :

~ $> cd devel/mon_client/projet_java8
Using java version 8.0.362-zulu in this shell.

Gérer vos versions de Maven et de Kotlin

En réalité, je n'utilise pas vraiment SDKMan pour jongler entre plusieurs versions de Maven ou Kotlin mais il s'agit surtout d'un outil très pratique pour les installer facilement et rapidement.

Installation de Maven

Si comme moi, vous ne vous souciez pas plus que ça de la version de Maven que vous aller récupérer à partir du moment que c'est la dernière en date, tapez juste la commande suivante dans un terminal :

$> sdk install maven
Downloading: maven 3.8.7
In progress...
########################################################################## 100,0%
Installing: maven 3.8.7
Done installing!

Installation de Kotlin

Pour Kotlin c'est un peu différent.

Ce langage est assez récent pour que la chance (ou la malchance) de devoir gérer plusieurs version de Kotlin est faible.

Cependant, vous pourrez, comme java, connaître les différentes version de Kotlin disponibles avec la commande suivante :

$> sdk list kotlin
================================================================================
Available Kotlin Versions
================================================================================
 > * 1.8.0               1.4.0               1.2.60              1.1.3          
     1.7.21              1.3.72              1.2.51              1.1.2-5        
     1.7.20              1.3.71              1.2.50              1.1.2-2        
     1.7.10              1.3.70              1.2.41              1.1.2          
     1.7.0               1.3.61              1.2.40              1.1.1          
     1.6.21              1.3.60              1.2.31              1.1            
     1.6.20              1.3.50              1.2.30              1.0.7          
     1.6.10              1.3.41              1.2.21              1.0.6          
     1.6.0               1.3.40              1.2.20              1.0.5-2        
     1.5.31              1.3.31              1.2.10              1.0.5          
     1.5.30              1.3.30              1.2.0               1.0.4          
     1.5.21              1.3.21              1.1.61              1.0.3          
     1.5.10              1.3.20              1.1.60              1.0.2          
     1.5.0               1.3.11              1.1.51              1.0.1-2        
     1.4.31              1.3.10              1.1.50              1.0.1-1        
     1.4.30              1.3.0               1.1.4-3             1.0.1          
     1.4.21              1.2.71              1.1.4-2             1.0.0          
     1.4.20              1.2.70              1.1.4                              
     1.4.10              1.2.61              1.1.3-2                            

================================================================================
+ - local version
* - installed
> - currently in use
================================================================================
(END)

Vous remarquerez d'ailleurs que j'ai déjà installé la dernière version (1.8.0 à l'heure où sont écrites ces lignes) sur mon poste.

Pour installer Kotlin dans sa dernière version, il vous suffira de taper en ligne de commande :

$> sdk install kotlin

Pour avoir une version spécifique comme la version 1.2.71 :

$> sdk install kotlin 1.2.71

Pour passer d'une version à une autre, c'est identique à ce que l'on a appris avec Java.

Et la suite ?

Dans mon prochain article, je vous expliquerais comment j'ai réussi à changer complètement de configuration Maven en fonction du répertoire où je me trouve...

Si ça vous intéresse, demandez-moi en contact ou suivez-moi sur LinkedIn !

J'aimerais aussi terminer en vous expliquer rapidement qui je suis 😄

Je m'appelle Hoani CROSS. Je suis originaire de Polynésie Française.

Aujourd'hui je suis manager et backend architect chez SFEIR, une Néo-ESN française. Une des particularités de SFEIR, c'est que les managers sont également des exécutants en mission chez des clients. On comprend ce que font les employés qu'on manage et croyez-moi, ça fait une sacré différence ! Et enfin, ce qui nous relie tous chez SFEIR, c'est la passion pour l'informatique... Étant donné qu'elle me suit depuis 40 ans, autant vous dire que je suis tombé au bon endroit !..

D'ailleurs, si vous êtes passionné.e comme moi, il y certainement une mission de rêve qui vous attend chez SFEIR alors n'hésitez pas à me contacter si vous voulez changer d'horizon.

Enfin, je suis aussi le propriétaire du blog Geek & Rentable, dont je vous conseille la visite. Avec ce blog, je souhaite aider les développeurs ou autre acteurs de la tech, passionnés mais malheureusement incompris, afin de faire évoluer leur condition de travail voire leur carrière.

À très bientôt.

DEV Community: Hoani CROSS

Changer son environnement fullstack en un clin d'oeil : partie 2 avec Maven

Ma façon préférée d'installer Maven

Comment Maven gère les environnements de développement

Comment ChatGPT m'a mis sur la voie

Avoir plusieurs fichiers de configuration

Un wrapper magique pour mvn

Retrouver le nom du fichier de configuration spécifique

Trouver le binaire mvn d'origine

Le corps principal du wrapper

Le script complet

Faire un wrapper vraiment complet

Rendre le wrapper disponible dans la variable d'environnement PATH

Limite de ce procédé dans les IDE

Et la suite ?

Changer son environnement fullstack en un clin d'oeil : partie 1 avec Java

Gérer vos versions de Java

Installer SDKMan

Téléchargez votre version de Java par défaut

Installer d'autres versions de Java

Passer d'une version de Java à une autre

Changement automatique de la version de Java

Gérer vos versions de Maven et de Kotlin

Installation de Maven

Installation de Kotlin

Et la suite ?

Un wrapper magique pour `mvn`

Trouver le binaire `mvn` d'origine

Rendre le wrapper disponible dans la variable d'environnement `PATH`