@mbarberot 🐿️

Installer un Raspberry Pi avec Docker

2019-04-08T12:00:00Z

Après avoir bien pris la poussière, j'ai enfin décidé de (re)faire quelque chose de mon Raspberry Pi. A l'origine, le Pi a été développé pour libérer le pouvoir créatif, mais j'ai toujours été rebuté par la maintenance d'un serveur Linux et le bazar que générait l'installation des bases de données, serveurs et autres outils.

Heureusement, maintenant nous avons les conteneurs ! Ils sont parfait pour expérimenter tout un tas de choses sans polluer la machine. J'ai donc choisi d'utiliser une distribution Raspbian Lite sans interface graphique, sur laquelle je vais installer Docker. Mon but est d'avoir un OS aussi dépouillé que possible de n'installer que des conteneurs contenant les applicatifs désirés.

Sources

Pour cette installation, je me suis aidé de plusieurs articles :

Matériel

un Raspberry Pi (version 2, B+)
une carte mémoire (SD Card)
de l'équipement réseau (câble RJ45, switch)
un autre ordinateur sous Linux (Mint)

1/ Préparation de la carte mémoire

Formattage

Tout d'abord on va préparer la carte, et il faut commencer par la formatter. Pour cela, on insère la carte dans le lecteur. Si comme moi, vous n'en avez pas un d'intégré à votre PC, un adapteur USB fera très bien l'affaire. Puis, j'ai utilisé l'utilitaire graphique Disks de Linux Mint pour trouver la carte parmis les supports de stockage et ensuite pour la formatter via le menu.

Notez bien chemin de la carte mémoire, ça sera utile plus tard. Pour moi, il s'agissait de /dev/sdc.

Téléchargement de Raspbian

Rien de sorcier, voici la page des téléchargements : Raspberry Pi Downloads.

Installation de Raspbian

Pour installer Raspbian, il suffit de copier le contenu de l'archive téléchargée sur la carte mémoire. Pour cela, j'ai utilisé l'utilitaire dd, qui prend en paramètre, entre autre le chemin de ma carte mémoire que j'avais pris le soin de noter auparavant.

unzip -p 2018-06-27-raspbian-stretch-lite.zip
    | sudo dd of=/dev/sdc conv=fsyncp

Un peu de configuration

Par défaut, SSH sera désactivé et ce sera facheux lorsqu'on voudra prendre la main à distance sur le Pi. Pour l'activer, il suffit de créer un fichier vide dans la partiion de boot sur la carte mémoire.

sudo mount /dev/sdc1 /mnt -o umask=000
touch /mnt/ssh

2/ Lancement !

La carte mémoire est prête. Il est temps d'insérer la carte, brancher le Pi au réseau et l'allumer. Une fois démarré, j'ai tiré parti de ma box internet (Livebox) pour assigner une IP statique et un nom (backupserver) au Pi depuis l'interface d'administration, puis je l'ai redémarré pour qu'il prenne en compte les changements.

La configuration réseau terminée, on peut se connecter en SSH en utilisant les identifiants par défaut : pi / raspberry

ssh pi@backupserver

Pour des raisons évidentes, on va en profiter pour changer tout de suite le mot de passe :

passwd

3/ Installation de Docker

Docker supporte désormais les architectures ARM. On va donc pouvoir l'installer assez facilement sur le Pi !

Preconfiguration

Avant de pouvoir installer Docker, un peu de configuration est nécessaire. Tout d'abord, il faut définir le hostname dans les fichiers suivants :

/etc/hosts
/etc/hostname

Ensuite, on va modifier le fichier /boot/config.txt pour modifier ou ajouter la ligne suivante :

gpu_mem=16

Installer Docker

Docker s'installe très facilement via la commande proposée sur le site officiel :

curl -sSL https://get.docker.com | sh

Configurer Docker

Dans mon cas, j'ai envie que Docker se lance toujours au démarrage du Pi, c'est pourquoi je configure systemd :

sudo systemctl enable docker

Et pour des raisons pratiques, on peut également configurer notre utilisateur pour lui permettre d'utiliser Docker sans avoir systématiquement besoin de sudo :

sudo usermod -aG docker pi

On peut maintenant redémarrer le Pi une nouvelle (et dernière) fois.

Profit

Le Raspberry Pi est désormais prêt à recevoir des conteneurs !

Serveur de backup : Samba

2019-04-09T12:00:00Z

Cet article fait suite à celui de l'installation sur un Raspberry Pi d'une distribution Raspbian Lite (sans UI) et de Docker. Vous pouvez retrouver cet article ici.

Sans grande originalité, j'ai donc décidé de transformer mon Pi en serveur de fichier pour faire mes sauvegardes et accéder à mes données depuis n'importe quelle PC du réseau local. Le "challenge" sera de le faire uniquement avec des conteneurs !

Dans cette première partie, nous allons voir comment faire la partie partage avec Samba.

Matériel

un Raspberry Pi avec Docker
un disque dur externe en USB

1/ Connecter le disque dur externe

Tout d'abord on va brancher le disque en USB sur le Pi. Etant formatté en NTFS pour pouvoir l'utiliser avec Windows, le Pi est capable de le monter nativement mais uniquement en lecture seule.

Pour pouvoir déposer des fichiers sur le disque dur, on va devoir le monter différement. Pour cela nous allons avoir besoin du paquet ntfs-3g :

sudo apt-get install ntfs-3g

Ensuite, on va devoir trouver le disque dur. Pour cela, je regarde habituellement dans /dev/disk. Dans mon cas, le disque dur était /dev/dsb. Je peux alors le monter via la commande :

sudo mount -o rw,uid=1000,gid=1000,umask=0077 \
    -t ntfs-3g \
    /dev/sdb /media/share

Notes :

-t ntfs-3g indique le format de la partition, ici nous sommes en NTFS avec le paquet installé précédemment
-o permet de donner des options
- uid=1000,gid=1000 indique quel utilisateur aura accès au disque dur. On peut trouver les uid et gid dans le fichier /etc/passwd.
- umask=0077 est un chmod inversé. Ici, je donne un accès en lecture et écriture.

2/ Lancer Samba avec Docker

Pas besoin de réinventer la roue, un conteneur Samba existe déjà sur Docker Hub : dperson/samba. Le conteneur dispose d'un script permettant de facilement configurer les utilisateurs et partages.

Voici la commande que j'ai utilisé :

docker run \
	--name samba \
	-d \
	--rm -it \
	-v /media/share:/mnt/share \
	--network host \
	dperson/samba:armhf \
	-n \
	-g "interfaces = 192.168.1.150" \
	-u "myuser;mypassword" \
	-s "Share;/mnt/share;yes;no;no;myuser;myuser" \
	-w "workgroup"

Je vous laisse regarder la documentation qui explique bien ce que font les options -u, -s et -w pour me concentrer plutôt sur les autres options.

D'une part pour Docker :

--network host permet au conteneur de se comporter au niveau réseau comme s'il était directement sur la machine hôte

D'autre par pour le conteneur :

-n pour démarrer NMDB qui permet de publier les partages, sans quoi le partage n'était pas visible sur les PC de mon réseau
-g "interfaces = <pi's IP>" qui indique quelle IP doit utiliser NMDB sans quoi il utilise une interface interne au conteneur

3/ Améliorations

Monter automatiquement le disque dur au démarrage du Pi

Comme nous avons fait le montage en ligne de commande, il sera perdu au prochain redémarrage. Pour éviter cela, nous allons l'ajouter dans /etc/fstab.

Tout d'abord, il faut trouver l'UID du disque dur :

$ sudo blkid
# [...]
/dev/sdb : LABEL="MyBackup" UUID="1E3BEA7C1AEA5087" TYPE="ntfs" PARTUUID="00015c12-01"
# [...]

Ensuite, on peut modifier /etc/fstab pour ajouter une ligne contenant les mêmes informations que la commande de mount.

# <uid> <mount point> <format> <options> <dump> <pass>
UUID="1E3BEA7C1AEA5087" /media/share	ntfs-3g	uid=1000,guid=1000,umask=0077	0	0

Lancer automatiquement Samba au démarrage du Pi

Dans la commande Docker, remplacer -rm par --restart=always.

Profit

Le partage Samba devrait être accessible depuis la section "Réseau" de l'explorateur de fichier. Si ce n'est pas le cas, vous pouvez également utiliser le chemin suivant : smb://192.168.1.150

Quelques astuces

2019-04-10T12:00:00Z

Vérifier si du XML a des caractères interdits

Serveur d'impression

2020-08-17T12:00:00Z

Cet article fait suite à celui de l'installation sur un Raspberry Pi d'une distribution Raspbian Lite (sans UI) et de Docker. Vous pouvez retrouver cet article ici.

Ici encore, on ne fait pas dans l'original. Vous trouverez facilement bon nombre de tutoriels pour transformer un Raspberry Pi en serveur d'impression. Mais là encore, on va le faire avec un conteneur.

Matériel

un Raspberry Pi avec Docker
une imprimante et son câble USB

1/ Connecter l'imprimante

Brancher l'imprimante au Pi via son câble USB et allumer l'imprimante. Normalement elle sera détectée automatiquement par l'OS.

2/ Installer CUPS

CUPS est un serveur d'impression. Il est trés répandu et est compatible avec tous les OS. Mon but étant de garder le système aussi minimal que possible, on va s'éviter les installations et configurations de CUPS en passant par Docker.

Voici la commande que j'ai utilisé :

docker run \
    --name cups \
    -d \
    -it \
    -p 631:631 \
    -v /var/run/dbus:/var/run/dbus \
    -v /dev/bus/usb:/dev/bus/usb \
    -e ADMIN_PASSWORD=MyCUPSP@ssw0rd \
    --privileged \
    --net=host \
    --restart=unless-stopped \
    ydkn/cups:latest

A noter :

--net=host permet au conteneur de se comporter au niveau réseau comme s'il était directement sur la machine hôte. C'est nécessaire car sans cela, l'interface d'administration ne serait disponible que depuis le Raspberry Pi et pas depuis un autre PC du réseau.
-v /var/run/dbus:... et -v /dev/bus/usb:... permettent l'accès à l'imprimante conectée en USB depuis le conteneur.

Pour le reste, je vous laisse aller regarder la documentation de Docker et de l'image CUPS.

3/ Ajouter l'imprimante dans CUPS

Une fois le conteneur lancé, on peut aller sur l'interface de CUPS, à savoir : l'ip de votre Pi (ip addr show) sur le port 631. Chez moi cela donne http://192.168.1.150:631.

Depuis cette interface, on va pouvoir aller dans la section "Administration", puis "Trouver de nouvelles imprimantes".

CUPS nous demande de s'authentifier et on arrive sur la page suivante pour choisir l'imprimante. CUPS a détecté mon imprimante, je peux directement l'ajouter.

Ensuite, CUPS nous demande quelques informations pour décrire l'imprimante :

On choisit ensuite la marque de l'imprimante :

Puis le modèle :

Vous pourrez ensuite ajouter de options d'impression ou prendre la configration par défaut.

Pour vérifier si l'imprimante est bien fonctionnelle, vous pouvez aller dans "Imprimantes", choisir l'imprimante que vous venez d'ajouter, puis dans le menu déroulant "Maintenance", choisissez "Imprimez une page de test"

4/ Profit

Lorsque vous ajouterez une nouvelle imprimante réseau sur votre PC, l'OS devrait automatiquement la trouver.

Serveur DLNA

2020-08-19T12:00:00Z

Cet article fait suite à celui de la mise en place de Samba sur un Raspberry Pi avec Docker. Vous pouvez retrouver cet article ici.

Disposant d'une TV connectée, j'ai rapidement découvert qu'elle pouvait lire des vidéos via le réseau. Pour cela, elle utilise le standard DLNA. On va donc voir ici comment mettre en place un serveur compatible DLNA sur le Raspberry Pi. Et comme pour les précédents articles, on va utiliser Docker !

C'est quoi un serveur DLNA

DLNA définit un standard d'interopérabilité permettant la lecture, le partage et le contrôle d'appareils multimédia indépendamment de leur marque ou de leur nature. (source : Wikipedia)

On va utiliser ici le serveur MiniDLNA pour sa simplicité : make each program do one thing well.

Materiel

un Raspberry Pi avec Docker
un disque dur externe en USB

1/ Pré-requis

Le disque dur est branché au Pi et on dispose d'un point de montage. Si besoin, la marche à suivre est indiqué dans l'article mentionné ci-dessus.

2/ Installer le serveur MiniDLNA

Voici la commande que j'ai utilisé :

docker run \
    --name dlna \
    -d \
    -it \
    --net=host \
    --user=1000 \
    --restart=unless-stopped \
    -v /media/share/videos:/media/videos \
    -e MINIDLNA_MEDIA_DIR=/media/videos \
    -e MINIDLNA_FRIENDLY_NAME=MyDLNA \
    vladgh/minidlna

--user=1000 permet de lancer le conteneur en utilisant l'utilisateur ayant l'uid 1000, ce user est celui qui dispose des droits sur le point de montage /media/share. On peut trouver l'uid d'un utilisateur en inspectant le fichier /etc/passwd.
-v /media/share/videos:... permet de monter une partie du disque dur dans le conteneur. Ensuite, on utilise -e MINIDLNA_MEDIA_DIR=/media/videos pour indiquer à MiniDLNA quel dossier utiliser.
-e MINIDLNA_FRIENDLY_NAME=... permet de définir le nom qui apparaitra sur le réseau.

Pour les autres options, je vous laisse regarder la documentation de Docker et de l'image vladgh/minidlna.

3/ Vérification

Vous pouvez aller inspecter les logs pour vérifier que le démarrage du serveur s'est bien déroulé. Pour cela, utilisez la commande suivante :

docker logs dlna

Dans ces logs, vous devriez voir apparaitre un section indiquant sur le serveur a bien pris en compte les dossiers que vous lui avez indiqué :

Scanning /media/videos
Scanning /media/videos finished (235 files)!

Et une section indiquant que le serveur est bien démarré :

Starting MiniDLNA version 1.2.1.
HTTP listening on port 8200

4/ Profit

Votre TV connectée devrait automatiquement découvrir le serveur et pourra lire les fichiers vidéos (ou audio) que vous aurez mis à disposition.

Serveur de numérisation

2020-08-19T12:00:00Z

Cet article fait suite à celui de l'installation sur un Raspberry Pi d'une distribution Raspbian Lite (sans UI) et de Docker. Vous pouvez retrouver cet article ici.

Après avoir installé un serveur d'impression dans un article précédent, nous allons maintenant voir comment également mettre le scanner à disposition sur le réseau, et là encore avec Docker pour minimiser le nombre d'action à réaliser sur le Pi.

Sources

Pour cette installation, je me suis aidé de plusieurs articles :

Matériel

un Rapsberry Pi avec Docker
une imprimante et son câble USB

1/ Connecter le scanner

Brancher le scanner au Pi via son câble USB et allumer le scanner. Normalement il sera automatiquement détecté

Dans mon cas, je dispose d'une imprimante/scanner tout-en-un. L'appareil est déjà branché au Pi depuis l'installation du serveur d'impression.

2/ Installer Sane

Sane est un serveur de numérisation. Il dispose de plusieurs clients pour être utilisable sur les différents OS existants. Hélas, peu d'images existent pour Raspberry Pi, on va donc créer notre propre image.

Pour cela, allez sur mbarberot/docker-saned et suivez les instructions du README pour créer l'image.

Ensuite, voici la commande que j'ai utilisé :

docker run \
    -d \
    -it \
    --name sane \
    -v /var/run/dbus:/var/run/dbus \
    -v /dev/bus/usb:/dev/bus/usb \
    -p 10000:10000 \
    -p 10001:10001 \
    -p 6566:6566 \
    --privileged \
    --net=host \
    --restart=unless-stopped \
    sane:latest

-v /var/run/dbus:... et -v /dev/bus/usb:... permettent l'accès à l'imprimante conectée en USB depuis le conteneur

Pour le reste, je vous laisse aller regarder la documentation de Docker.

3/ Profit

Le scanner devrait être accessible depuis le réseau. Le site de Sane dispose d'une page référençant les différents clients.

Pour ma part, j'ai opté pour :

Simple Scan sous Linux, il s'agit de l'utilitaire installé par défaut sous Linux Mint et il fonctionne parfaitement avec Sane.
SaneTwain sous Windows, c'est rustique mais ça fonctionne bien.

Dépendences transitives et “unresolved requirement” error dans Liferay

2022-06-29T12:00:00Z

Avec le passage à OSGi, la gestion du classpath ajoute son lot de surprise. Ainsi, on peut voir apparaitre l’erreur suivant lors du déploiement d’un module :

Could not resolve module: com.mbarberot.module.lorem [2008]_  
		Unresolved requirement: Import-Package: org.foo.utils_

Dans la plupart des cas, org.foo.utils est le package d’une dépendance ajoutée au module. Par défaut, OSGi va aller chercher ce package dans sa liste de package qui provient des différents Export-Package des modules déployés. Il faut donc lui signifier qu’il s’agit en fait d’un package qu’il doit aller chercher au sein de notre module. Pour cela, nous pouvons ajouter cette instruction au bnd.bnd:

Private-Package: \
    org.foo.*

Hélas, c’est alors qu’une nouvelle erreur peut survenir :

Could not resolve module: com.mbarberot.module.lorem [2008]_  
		Unresolved requirement: Import-Package: org.bar.annotations_

Pourtant, nulle trace de ce package dans le code ! Il s’agit en fait d’un package utilisé dans org.foo car OSGi va venir également regarder les dépendances transitives !

Hélas, dans ce cas, ajouter le package dans Private-Package ne fonctionnera pas car ce n’est pas notre propre code qui vient importer ce package.

Dans ce cas, on peut venir blacklister ce package dans la partie Import-Package dans le bnd.bnd :

Private-Package: \
    org.foo.*
Import-Package: \
    !org.bar.*, \
	  *

Attention à ne pas oublier le wildcard en dernier, sans quoi OSGi n’ira plus chercher aucun package et ne trouvera aucune classe appartenant aux dépendances “provided” : Liferay, vos autres modules, ...

Une entrée dans le menu utilisateur qui exécute du Javascript

2022-06-29T12:00:00Z

Pour cela, on va créer un module de base :

blade create --template api my-portlet-entry

On retouche le bnd.bnd pour ne rien exporter :

Bundle-Name: My Portlet Entry
Bundle-SymbolicName: fr.mbarberot.myportlet.menu.entry
Bundle-Version: 1.0.0
-metatype: *
-plugin.metatype: com.liferay.ant.bnd.metatype.MetatypePlugin

On supprime le code généré et on ajoute notre composant :

@Component(
    immediate = true,
    property = {
				// 1️⃣
        "product.navigation.personal.menu.entry.order:Integer=100",
        "product.navigation.personal.menu.group:Integer=100"
    },
    service = PersonalMenuEntry.class
)
public class ClickMePersonalMenuEntry implements PersonalMenuEntry { // 2️⃣ 

    private ResourceBundle resourceBundle = 
				ResourceBundleUtil.getBundle(
					"content.Language", 
					this.getClass().getClassLoader()
		);

    @Override
    public String getLabel(Locale locale) {
        return LanguageUtil.get(resourceBundle, "click-me");
    }

    @Override
    public String getPortletURL(HttpServletRequest httpServletRequest) {
        // 3️⃣
        return "javascript:" + 
						"function showDialog() {" +
	            "jQuery('.click-me-dialog').click();" +
            "};" +
            "showDialog();";
    }
}

Voici les points clés de ce code :

Premièrement (1️⃣), les properties indiquent à quel endroit notre entrée de menu se placera au sein de ce menu. Ici, ce sera le premier item

Ensuite (2️⃣), on utilise directement l’interface PersonalMenuEntry pour avoir la main sur la méthode getPortletURL et on doit également implémenter la méthode getLabel.

Enfin (3️⃣), la chaîne de caractères qui sera retournée de getPortletURL sera directement placée dans le href de l’item du menu. On peut donc lui indiquer du javascript comme dans l’exemple.

A noter cependant : si la méthode retourne des données, le lien effectuera un changement de page ! Il faut donc bien faire attention à ne rien retourner. Ainsi, on ne peut pas directement utiliser la méthode jQuery car ses méthodes retourneront toujours un résultat ou this (pour pouvoir faire une chaîne d’appel), d’où la syntaxe utilisée dans l’exemple.

Déplacement en Camel Case avec IdeaVim

2022-08-19T12:00:00Z

Si comme moi, vous travaillez sur un langage dont la convention de nommage est le CamelCase et que vous utilisez les motions de Vim, vous avez peut-être également eu cette frustration de ne pas pouvoir sauter d’un “mot” à l’autre dans un nom de variable ou de classe.

L’alternative que j’ai utilisée pendant des mois est la suivante :

// Goal : Change "Foo" with "Bar" in a CamelCase word
<caret>SomeAwesomeFooService
// Place the caret at Foo : "fF" ou "/Foo<Enter>"
SomeAwesome<caret>FooService
// Change the Foo part : "ctS" and then type "Bar<Enter>
SomeAwesomeBarService

Cette méthode est assez efficace mais parfois juste frustrante de devoir indiquer spécifiquement les lettres majuscules dans les commandes. J’aimerais avoir une commande intuitive que l’on puisse taper avec le minimum de réflexion comme peuvent l’être les commandes w, b, e.

Après quelques recherches, voici ce que j’ai pu réussir à mettre en place :

// Goal : change "Foo" with "Bar" in a CamelCase word
<caret>SomeAwesomeFooService
// Move the caret to the next "word" inside CamelCase : "<leader>w"
Some<caret>AwesomeFooService
// Again : "<leader>w"
// Of course, I could have used "2<leader>w" directly
SomeAwesome<caret>FooService
// Change the Foo part : "c<leader>w" and then type "Bar<Enter>"
SomeAwesomeBarService

Et voici comment le mettre en place avec quelques lignes de configurations dans le .ideavimrc :

let mapleader = " "

"" Camelcase motion
" Can be used with dw, cw, yb, etc
noremap <leader>w [w
noremap <leader>e ]w
noremap <leader>b [b

Vous pouvez mettre la touche que vous voulez dans le mapleader. Ce sera la touche représentée par <leader> dans la suite du fichier.

Comme vous pouvez le voir, j’utilise la touche espace qui est facilement accessible depuis le pouce et me permet de taper la suite de la commande avec mes autres doigts.

A noter :

https://youtrack.jetbrains.com/issue/VIM-1984/Support-CamelCaseMotionvim-plugin
https://stackoverflow.com/questions/71631159/ideavim-move-between-words-in-camel-case-word

Filtering avec Gradle

2023-03-29T12:00:00Z

La problématique

J’ai plusieurs vues et chacune d’entre-elles possède un fichier Javascript qui lui est dédié. Pour le charger, j’utilise la taglib liferay-util afin d’injecter le fichier à la fin de la page :

<!-- views/foo.jsp -->

<!-- ... -->

<liferay-util:html-bottom>
    <script src="/o/foo-portlet/js/foo.js"></script>
</liferay-util:html-bottom>

Lors du déploiement du module, aucun problème, tout fonctionne comme prévu. En revanche, lors des déploiements suivants, Liferay a mis en cache le fichier, et mes nouveaux développements ne sont pas pris en compte, et cela devient rapidement une source de frustration et une perte de temps.

Solutions étudiées

Désactiver le “fast-load”

Mon premier réflexe a été de désactiver cette option via le fichier de configuration portal-ext.properties :

theme.js.fast.load=false

Hélas, cela ne fonctionne pas avec les fichiers injectés de cette manière.

Vider la cache depuis l’interface d’administration

Étonnamment, cette méthode ne semble pas fonctionner dans mon cas de figure, et de toute manière c’est rapidement fastidieux de devoir aller vider la cache après chaque déploiement.

Utiliser la configuration du portlet

Une autre manière est d’utiliser la configuration du portlet. En effet Liferay gère bien mieux l’invalidation du cache de cette manière, car il ajoute lui-même un timestamp lors de l’injection du fichier dans la page :

@Component(
    immediate = true,
    property = {
        "com.liferay.portlet.footer-portlet-javascript=/js/foo.js",
        // ...
    },
    service = Portlet.class
}
public class MyPortlet extends MVCPortlet { 
  // ...
}

Encore hélas, cette solution ne convient pas à mon cas de figure, car elle injectera tous les fichiers, quelque soit la vue et je ne veux charger que le fichier nécessaire à chaque vue.

Modifier le nom du fichier Javascript

Vu que Liferay se base sur le nom du fichier, on peut facilement contourner le cache en changeant le nom du fichier avant chaque déploiement. Réaliser cette opération manuellement nécessite d’une part de renommer le fichier, puis de mettre le nouveaux nom dans le fichier JSP, ce qui devient rapidement fastidieux.

Utiliser Gradle pour générer un suffixe automatiquement

Avec Maven, on dispose d’un mécanisme de Filtering qui permet de remplacer des tokens particuliers placés dans les fichiers du projet par des valeurs indiquées dans la configuration du build. Gradle dispose également de cette fonctionnalité, et nous allons pouvoir l’utiliser pour ajouter automatiquement un suffixe aux imports des scripts. Ce token particulier est une simple chaîne de caractères entourées d’un @ de part et d’autre. Voici ce que cela donne dans mon exemple :

<liferay-util:html-bottom>
    <script src="/o/foo-portlet/js/foo-@timestamp@.js"></script>
</liferay-util:html-bottom>

Une fois les fichiers JSP prêts, il faut désormais configurer Gradle.

Tout d’abord, on va créer une variable avec la valeur du suffixe :

def timestamp = 'v1'

On va ensuite activer le Filtering en configurant la tâche processResources

import org.apache.tools.ant.filters.ReplaceTokens

// ...

processResources {
    filter ReplaceTokens, tokens: [
        "timestamp": timestamp
    ]
}

On va ajouter une nouvelle tâche pour ajouter automatiquement le suffixe aux fichiers Javascript :

task cacheBusting (type: Copy) {
    with copySpec {
        from('src/main/resources') {
            include '**/*.js'
        }
        rename('(.*)\\.js', "\$1-${timestamp}.js")
    }
    into("$buildDir/resources/main")
}

En l’état, les fichiers Javascript sont copiés deux fois, l’une par notre tâche avec les suffixe, et l’autre par processResources sans le suffixe. On va donc lui retirer ces fichiers :

processResources {
    // ...
    exclude('**/*.js')
}

Enfin, on va brancher notre tâche cacheBusting au sein du processus de build Gradle :

task cacheBusting (type: Copy) {
    // ...
    dependsOn(processResources)
}

jar {
    dependsOn(cacheBusting)
}

Configuration finale

// ...

import org.apache.tools.ant.filters.ReplaceTokens
def timestamp = "v1"

processResources {

    // replace @timestamp@ with the defined value in every resource files
    // note : it uses Ant under the hood
    filter ReplaceTokens, tokens: [
        "timestamp": timestamp
    ]

    // do not process js files to let cacheBusting task handle them
    exclude('**/*.js')
}

// handle js files with this new task to rename them with the timestamp
task cacheBusting (type: Copy) {

    with copySpec {
        from('src/main/resources') {
            include '**/*.js'
        }
        rename('(.*)\\.js', "\$1-${timestamp}.js")
    }
    into("$buildDir/resources/main")

    dependsOn(processResources)
}

jar {
    dependsOn(cacheBusting) // insert the task into the gradle lifecycle
}

Résultat

build
├── resources
│   └── main
│       ├── content
│       │   └── Language.properties
│       └── META-INF
│           └── resources
│               ├── css
│               │   └── main.scss
│               ├── images
│               │   └── foo.jpg
│               ├── init.jsp
│               ├── js
│               │   ├── bar-v1.js
│               │   ├── baz-v1.js
│               │   └── foo-v1.js
│               └── views
│                   ├── bar.jsp
│                   ├── baz.jsp
│                   └── foo.jsp
...

<!-- foo.jsp -->

<!-- ... -->

<liferay-util:html-bottom>
    <script src="/o/foo-portlet/js/foo-v1.js"></script>
</liferay-util:html-bottom>

Installer Blade CLI

2023-10-25T12:00:00Z

Tout d’abord : la documentation officielle

Un lien vous mènera sur SourceForge.

Choisir la dernière version stable :

Choisir ensuite l’exécutable sans le DevStudio et en fonction de votre OS :

Enfin : suivre la documentation officielle qui indique les options à choisir pendant l’installation.

Attention, sous Windows, vous pourrez avoir l’erreur suivante :

Error running C:/Program Files/.../bin/java.exe-jar 
"C:/Program Files (x86)\...\biz.a.Qute.jpm.run.jar" 
-u init: Error 0. Failed to run platform init, exit code -2137483648

Elle survient lorsqu’il manque une clé de registre qui est normalement créée lors de l’installation du JDK. Si vous avez installé votre JDK manuellement, utilisez un installeur à la place. Vous devriez trouver toutes les versions sur la site de la fondation Eclipse : Adoptium.