Antichesse (o ^ω^ o)
Pour faire simple, les workspaces de Cargo sont l'équivalent des modules de Maven.
Pour définir une configuration commune à tous les workspaces il faut ajouter ceci dans le Cargo.toml à la racine du projet :
[package]
name = "sotoestevez_medium"
version = "0.1.0"
[workspace]
members = ["add_trait", "beginning_tips", "generify_with_compiler_errors", "modules", "scoped_threads" ]
[workspace.package]
edition = "2021"
authors = ["Soto Estévez <ricardo@sotoestevez.dev>"]
description = "Demos of the articles at https://medium.com/@sotoestevez"
documentation = "https://medium.com/@sotoestevez"
readme = "./README.md"
homepage = "https://www.sotoestevez.dev"
repository = "https://github.com/kriogenia/medium"
license = "MIT OR Apache-2.0"Puis activer l'héritage dans chaque Cargo.toml des workspaces :
[package]
name = "add_trait"
version = "0.1.0"
edition.workspace = true
authors.workspace = true
description = "Dissecting Rust Traits to Learn Their Secrets"
documentation = "https://betterprogramming.pub/dissecting-rust-traits-to-learn-their-secrets-839845d3d71e"
homepage.workspace = true
repository.workspace = true
license.workspace = trueCela marche aussi avec les versions des dépendances. Dans le parent on déclare ceci :
[workspace.dependencies]
num = { version = "0.4", default-features = false }
vector2d = "2.2"
rand = "0.8.5"Et dans les enfants ceci :
[dependencies]
num = { workspace = true, default-features = true }
vector2d.workspace = true
[dev-dependencies]
rand = { workspace = true, features = [ "log" ] }
Pour faire simple, l'équivalent du .m2/repository ou du répertoire cache des node_modules de npm n'existe pas en Rust / Cargo 😭
En résumé
- Soit il faut publier ses libs privées sur crates.io et donc les rendre publiques 🤬.
- Soit il faut installer l'équivalent d'un Artifactory perso quelque part 🤮.
- Soit il faut bidouiller / ruser 😩.
Parmi les bidouilles il y en a deux dont une acceptable je pense. Il faut déclarer le chemin vers le repo Git de la dépendance et non le nom et la version de la dépendance dans le fichier Cargo.toml du projet.
Ce qui nous donne
[dependencies]
regex = { git = "https://github.com/rust-lang/regex.git", branch = "1.0.0" } À la place de
[dependencies]
regex = "1.0.0"Le paramètre branch peut être une branche ou un tag. S'il n'est pas présent alors c'est le dernier commit sur la branche master qui sera utilisé.
Quid des fanatiques qui utilisent l'appellation main à la place de master ? #DoNotCare
L'autre option consiste à déclarer le chemin relatif ou se trouve la dépendance (ici regexp) sur notre disque dur dans le fichier Cargo.toml à la place du répo Git.
Ce qui rend le build non portable d'un développeur à l'autre puisque dépendant de la hiérarchie des dossiers, donc je vais éviter d'en parler.
Attention, Java 6 n'étant plus supportée les dépendances kotlin-stdlib-jdk7 et kotlin-stdlib-jdk8 n'existent plus (puisque c'est Java 8 la version minimale requise pour Kotlin à présent).
Il faut donc les remplacer par kotlin-stdlib. Une migration simple qui va poser de nombreux problèmes à certains, sans aucun doute.
Je suis en train d'analyser le partie front du projet d'un client et j'ai le sentiment qu'une tripotée de dépendances y est tirée alors qu'elles ne sont pas utilisées. depcheck est un utilitaire qui lit votre package.json puis parcours votre code afin de déterminer si les dépendances déclarées sont bel et bien utilisées, sinon c'est que vous pouvez les mettre à la poubelle.
Pour obtenir un rapport HTML détaillant quels JAR sont utilisés, inutilisés ou en conflits il faut utiliser la commande :
mvn dependency:analyze-reportPour un rapport directement dans la console c'est par ici.
Merci à @Philou pour l'astuce.
Les secrets des dépendances en JS.
Trouver quels jars sont en conflits dans votre build Maven en une ligne : mvn dependency:tree -Dverbose
Afin de renforcer vos build Maven et garantir que vos 'pom.xml' ne tirent pas de dépendances inutiles vous pouvez configurer votre maven-dependency-plugin avec l'exécution suivante :
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>analyze</id>
<goals>
<goal>analyze-only</goal>
</goals>
<configuration>
<failOnWarning>true</failOnWarning>
<outputXML>true</outputXML>
</configuration>
</execution>
</executions>
</plugin>Je me note la dépendance :
<dependency>
<groupId>com.oracle.substratevm</groupId>
<artifactId>svm</artifactId>
<version>1.0.0-rc8</version>
<scope>provided</scope>
</dependency>Il faudra que je fasse un poc à ce sujet.
Vous travaillez avec Maven depuis une connexion de merde. Ce dernier tente de télécharger 5 ou 6 artifacts de plusieurs méga en parallèle alors que votre vitesse de connexion n'excède pas les 16 Ko / sec (saloperie de H+ Free Mobile... Je dis ça, je ne dis rien mais on dirait du Edge). Bref, il serait plus rentable pour vous de télécharger les artifacts l'un après l'autre, d'autant que si votre connexion plante, vous avez plus de change de posséder un artifact en version complète dans votre répo local. Du coup voici la commande magique à fournir à Maven pour le forcer à s'exécuter en mode mono-thread et donc "no parallel downloads" :
mvn -Dmaven.artifact.threads=1 clean install