Antichesse (o ^ω^ o)
Je me le note pour plus tard, comment ne copier que les dépendances en scope "compile" via le maven-dependency-plugin :
mvn dependency:copy-dependencies -DincludeScope=compile
Bon, je vais résumer ici les différents scopes de Maven parce que l'outil évolue !
compile :
Si A déclare B en scope "compile" alors A tire B ainsi que toutes ses dépendances transitives au moment de la compilation, des tests, du packaging et du run.
test :
Si A déclare B en scope "test" alors A tire B ainsi que toutes ses dépendances transitives mais uniquement au moment de l'exécution des tests.
provided :
Si A déclare B en scope "provided" alors A tire B ainsi que toutes ses dépendances transitives au moment de la compilation, des tests, mais pas du packaging. Aussi, il faudra que B et ses dépendances transitives soient présentes sur l'environnement de run pour que tout fonctionne (typiquement, c'est le cas avec un Tomcat).
system :
Fait la même chose que "provided" mais avec les API native du système d'exploitation (eg. C / Rust, etc). Ce scope est à utiliser principalement lorsque l'on fait du JNI (Java Native Interface).
runtime :
Fait la même chose que "provided" mais pour les micro-services et non les serveurs d'applications. Dit autrement, la dépendance n'est pas accessible au moment de la compilation, donc il n'est pas possible de l'importer explicitement dans votre code, cependant cette dépendance sera incluse dans le package généré et copiée avec vos JAR ; contrairement aux dépendances en scope "provided" qui elles ne sont pas copiées dans le package générée puisqu'elles sont fournies par le serveur d'application.
import :
Si A déclare B en scope "import" alors A inclura la section <dependencyManagement> de B. A noter que ce scope ne peut être affecté à une dépendance que si celle-ci est déclarée dans la section <dependencyManagement> de A.
Je copie-colle l'explication courte (suffisante pour comprendre l'idée ou pour un mémo) :
abstract, open, final, sealed, override: drive inheritance, obviously affect the language
enum: alters the syntax of the declaration (allows enum entry list)
annotation: alters the syntax: annotation classes have no bodies
inner: alters scoping: members of outer class are accessible
private, public, internal, protected: regulate visibility, affect name/overload resolution
out, in: affect subtyping
vararg: affects use-site syntax, types and overload resolution
companion: affects both use-site and declaration-site syntax
lateinit: affects the syntax: initializer is forbidden, no definite-assignment checks are performed
inline, noinline, crossinline: affect possible usages of local returns etc
reified: affects possible arguments and uses of a type parameter inside
tailrec: affects allowed contents of a function
external: affects syntax: non-abstract function with no body
data: affects the set of members of a class, inheritance rules etc