Explication détaillée des puissantes balises de portée dans maven

Explication détaillée des puissantes balises de portée dans maven

Objet de cet article

  Poursuivant le résumé et la compréhension du numéro de version version de maven
  lorsque j'emballais le toolkit , j'ai trouvé quelques dépendances qui doivent être utilisées dans le code de l'outil, telles que la méthode jarutilisée dans le toolkit que j'ai créé, le package.   Mais parce que nous sommes tous des projets, comme ce package sera certainement dans le sous-projet à l'avenir, par exemple, via reference , le package sera automatiquement intégré. Il y aura alors un conflit de références. Comme le montre la figure ci-dessous :    Généralement, dans ce cas, il n'y aura pas de problème, les outils de développement de base et les compilateurs donneront automatiquement la priorité à l'un d'entre eux. (Selon le mécanisme de médiation, j'écrirai à ce sujet plus tard)    Mais en tant qu'agriculteur de code qualifié, bien que ce genre de chose ne soit pas un gros problème, les références désordonnées violent mon intention initiale rigoureuse. Par conséquent, le protagoniste de cet article est le meilleur moyen de nous aider à résoudre ce problème.springspring-web
springspring-boot-starter-webspring-web


scope

texte

1. qu'est-ce que c'estscope

   Par exemple, l'image suivante, regardez scopela position :

<dependency>
   <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.19</version>
    <scope>runtime</scope>
</dependency>

2. scopeLa notion de

  Tout d'abord, nos mavendépendances de projet sont en fait divisées en trois périodes, 编译期, 测试期, 运行期, c'est-à-dire que lors de la compilation du code, nous devons utiliser un ensembleclasspath ; lors des tests, nous avons besoin d'un autre ensemble de dépendancesclasspath ; et lorsque le projet est en cours d'exécution, nous besoin d'un autre ensemble de dépendances ensembles de dépendances classpath.

  scopeCommunément appelée plage de dépendance. Grâce à une configuration raisonnable, il est possible de contrôler la relation de la dépendance actuelle prenant effet à différents 编译期moments .测试期运行期

3. scopeClassement des

   scopeIl en existe compile, test, provided, runtime, system, importplusieurs sortes.

• compile : appelé portée de dépendance de compilation. Si la dépendance référencée ne spécifie pas de portée, cette portée de dépendance sera utilisée par défaut. L'utilisation de cette plage de dépendance signifie qu'elle est valide pour les 编译期, 测试期et 运行期les trois mentionnés ci-dessus classpath.
• test : Appelé la portée de dépendance de test. Valable uniquement 测试期pour le chemin de classe, généralement JUnitles dépendances, nécessaire uniquement lors de la compilation du code de test (src/test) et de l'exécution des tests.
• provide : La portée de la dépendance est fournie. Valable pour 编译期, 测试期chemin de classe. L'utilisation de cette plage de dépendance signifie que la dépendance actuelle sera référencée par défaut par le projet de référence à l'avenir, il n'est donc pas nécessaire de la référencer davantage. Dans la situation présentée au début de cet article, vous pouvez spring-webajouter <scope>provided</scope>des balises aux dépendances dans le projet d'outil.
• runtime : étendue de la dépendance d'exécution. Valable pour 测试期, 运行期chemin de classe.
• system : portée dépendante du système. Cette dépendance providedest identique à la portée de la dépendance, mais lorsque vous utilisez cette dépendance, vous devez spécifier systemPathune étiquette et afficher jarle chemin de la dépendance spécifiée. L'utilisation de cette plage de dépendances signifie rechercher des dépendances à partir du disque local, et non mavenles résoudre à partir de l'entrepôt. Faites attention lorsque vous utilisez cette dépendance, car vous recherchez des dépendances à partir de votre propre disque local, donc si plusieurs personnes développent ensemble, ce sera gênant et vous devrez copier cette dépendance sur le même chemin sur l'autre machine jar. Par conséquent, il n'est pas recommandé d'utiliser cette portée de dépendance.
• import : portée de la dépendance d'importation. Cette dépendance est sans effet sur les trois périodes mentionnées ci-dessus classpath. Les dépendances de cette portée ne sont dependencyManagementvalides que pour les balises. Sa fonction est de fusionner les dépendances de la balise dans la 目标pombalise actuelle pour les utiliser dans le projet référencé. En raison de la particularité des dépendances, généralement lorsque vous voyez la portée, elle existera , c'est-à-dire qu'elle pointe vers le module dont le type d'emballage est . Par exemple, les éléments suivants :dependencyManagementpomdependencyManagementimportimport<type>pom</type>pom

<dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>1.5.4.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
</dependencyManagement>

4. Dépendances transitives

  Lorsqu'un projet fait référence à mybatis-plus-boot-starterun package, parce que les dépendances sont configurées dans son pom mybatis-pluset que la portée est déclarée, compileaprès avoir introduit la première, j'introduirai également la seconde dans le projet, comme indiqué dans la figure ci-dessous, cela s'appelle 传递性依赖. ideaLes dépendances du projet que j'ai examinées :

  De plus, les dépendances pour mybatis-plus-boot-starteret pompour sont les suivantes :   c'est-à-dire qu'il est déclaré , donc pour lui, parce qu'il est déclaré , cela signifie qu'il est valide dans les trois types de , et , et notre projet fait référence , le même est utilisé . Cela permettra à notre projet d'avoir les deux .    Si nous modifions différentes valeurs, nous verrons différents effets de dépendance. Pour des effets spécifiques, reportez-vous à la figure ci-dessous dans "Maven Combat":    Par conséquent, la portée des dépendances contrôle non seulement la relation entre les trois dépendances, mais affecte également la transmission de la dépendance. .mybatis-plus

compilemybatis-plus-boot-startermybatis-pluscompilemybatis-plus-boot-starter编译期测试期运行期classpathmybatis-plus-boot-startercompilemybatis-plus
<scope>

scopeclasspath

5. scopeScénarios d'application

  Cela dit scope, le développement général ne s'en soucie peut-être pas du tout, mais si vous voulez être plus rigoureux, vous devez les prendre en compte pour vous assurer que la gestion des dépendances du projet est plus standardisée.
   Parce que chaque entreprise a un architecte, l'architecte est responsable de la mise à niveau et de la transformation du cadre de base, et les choses qu'il fait seront regroupées dans plusieurs packages Jar dépendants à l'avenir, les placeront sur le serveur privé de l'entreprise et seront utilisés directement par des projets de référence à l'avenir.
   Par exemple, il est convenu que le projet adopte springboot + mybatis-plus + lombok + shiro + druidces différentes versions, et ces différentes versions ne doivent pas être référencées par chaque projet. L'architecte doit se mettre d'accord sur la version, faire la configuration de base en plusieurs Jars, et définir ces dépendances liées à (si non écrit, la valeur par défaut est <scope>compile</scope>compile ), de sorte que chaque sous-projet n'a pas besoin de référencer ces dépendances séparément.
   Pour certains packages individuels, tels que les projets de référence qui seront certainement référencés à l'avenir, le package jar de dépendance peut être défini sur <scope>provided</scope>, par exemple, le package mentionné au début spring-web.

Pourquoi la structure du    prochain projet maven est-elle comme celle-ci