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" ] }
Maven 4 s'approche tout doucement, boosté par l'arrivée bienvenue de Maven Daemon (dont la 1.0.0-m1 se base sur la alpha-3 de Maven 4).
Bref, le comportement de Maven change un peu sur les projets multimodules. @Animal & @Kysofer je vous recommande de lire cela à tête reposée.
Un tuto clair et rapide sur les modules en JS. Pour toi @Animal :D
Différence entre les modules JavaScript (CommonJS, AMD, UMD et ESM). J'oublie tout le temps lequel est lequel.
Bref dans mon cas c'est :
- ESM quand on peut car c'est la norme ES6.
- Sinon UMD qui marche côté back et front.
- Sinon AMD pour le front (et qui reste asynchrone comme le premier).
- Sinon CommonJS (CJS) surtout pour le back (même s'il marche pour le front).
Je suis en train de travailler sur la fabrication de JRE custom s'appuyant sur Java 17 mais cela ne servira à pas grand chose si le code que nous produisons ne déclare pas bien les modules sur lesquels il s'appuie.
Rappel, une façon de créer des modules en C :
/* interface.h */
struct library {
const int some_value;
void (*method1)(void);
void (*method2)(int);
/* ... */
};
extern const struct library Library;
/* interface.h */
/* interface.c */
#include "interface.h"
void method1(void)
{
...
}
void method2(int arg)
{
...
}
const struct library Library = {
.method1 = method1,
.method2 = method2,
.some_value = 36
};
/* end interface.c */
/* client code */
#include "interface.h"
int main(void)
{
Library.method1();
Library.method2(5);
printf("%d\n", Library.some_value);
return 0;
}
/* end */Imaginez, vous êtes en prestation pour une grosse boite et la cellule d'architecture de votre client active tout un tas de plugins Maven sans comprendre comment fonctionnent ces plugins et ni Maven d'une manière générale.
Vous souhaitez donc bloquer l'héritage de la configuration de ces plugins pour ne laisser que les vôtres. Évidemment vous êtes quand même obligé d'hériter du pom parent provenant de la cellule d'architecture pour récupérer quelques properties bien utiles.
Solution :
1) Vous créez un pom abstrait à la racine de votre projet.
2) Dans ce pom vous ajoutez plugin par plugin (ici avec ANT) la désactivation <inherited>false</inherited>:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
<inherited>false</inherited>
...
</plugin>
</plugins>
</build>
...
</project>3) Vous créez un second pom abstrait, enfant du premier et duquel héritera tous vos modules.
Et voilà, les modules n'auront plus connaissance des plugins du super-parent.
Un tuto en français sur les modules de Java 9.
Tout est dans le titre.
Un description bien pratique de l'usage des modules de Java 9. En résumé, le classpath disparaît au profit du module-path, ce qui est public devient public uniquement à l'intérieur du JAR dans lequel la chose se trouve. Pour être public à toute l'application, il faut que les éléments soient exportés par le module.
Pas mal de rework en perspective.
Un descriptif de quelques modules NodeJS très sympa
Une brève description tirée de la Wikipédia expliquant à quoi servent chacun des modules d'Hibernate et par extension quand les utiliser dans un projet.
Hibernate se compose de plusieurs modules développés par des équipes différentes.
Core
Le module principal d'Hibernate contient les fonctionnalités clefs (principalement connues depuis la version 2 de la bibliothèque) telles que les sessions, les transactions, le cache d'objet ou le langage SQL.
Annotations
Apporte le support des Annotations tel que décrit dans JSR 175. Cette approche permet d'éviter la description de la correspondance entre les champs d'une table et les champs du POJO en XML.
Entity managerModifier
Permet le support de JSR 220 JPA par le module Core.
Shards
Ce module permet la partition horizontale du Core Hibernate.
Validator
Module de validation des contraintes d'entité de la base de données, implanté sous forme d'annotations telles que les plages de valeurs autorisées, les formats de chaine de caractères, la détection des valeurs nulles, etc.
Search
Le dernier module apporte une couche d'abstraction pour la recherche de Lucene appliquée sur les entités persistantes maintenues par Hibernate.
Tools
Ensemble d'outils pour Ant ou Eclipse facilitant le développement avec Hibernate."
Fabriquer un micro-service à partir d'un Jetty embarqué et sélectionner les modules de Jetty pour que son micro-service soit modulaire.
Enjoy :D
Module Peltier pour refroidir ou produire de l'électricité.
Merci Oros ! Tu gères petite fougère :D