Quelle est la différence entre ces Maven dependency étendues: fourni/compiler/système/importation

J'ai lu la documentation et ont une certaine compréhension.

Merci de corriger ou m'informer de la vérité, selon ma compréhension:

  • provided
    Les dépendances doivent sera sur la machine que vous exécutez le code, et doivent être inclus dans le chemin d'accès

  • compile
    Les dépendances ne seront pas sur la machine qui exécute le code, afin de les inclure dans la construction

  • system
    Exactement les mêmes que celles prévues, mais vous avez besoin de les dépendances d'être présent dans un fichier jar strictement

  • import
    Semble qu'il faut importer les dépendances de certains autres POM fichier mais je ne sais pas comment/pourquoi, alors, un peu d'élaboration serait appréciée

InformationsquelleAutor Programming Noob | 2013-06-03
  1. 55

    Vous vous trompez/ambiguës sur provided. Il signifie, "Ce pot doit être compilé avec localement, mais il sera fourni sur le chemin de la classe par quelque chose d'autre au cours de l'exécution, afin de ne pas l'inclure dans le classpath pour moi." Par exemple, tous les conteneurs web (ex: tomcat) comprennent les pots pour les servlets. Vous devez utiliser provided pour la servlet classes de sorte que vous pouvez compiler votre code en local, mais vous ne voulez pas remplacer les servlets tomcat fournit pour vous lorsque vous déployez pour elle.

    system signifie, "Ces dépendances sont sur mon système et je tiens à signaler directement". Vous voulez éviter si vous le pouvez, car une autre personne sur un autre ordinateur n'a pas nécessairement ces dépendances.

    La différence entre provided est plus facile à montrer:

    <dependency>
  <groupId>javax.sql</groupId>
  <artifactId>jdbc-stdext</artifactId>
  <version>2.0</version>
  <scope>system</scope>
  <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

    Voir comment il a que <systemPath>? C'est toute la différence. Vous n'avez pas à spécifier le chemin d'accès avec provided, à condition sait comment obtenir la dépendance à partir d'un référentiel. system l'obtient à partir de votre système de fichiers uniquement.

    Je n'ai jamais entendu parler de import. @JigarJoshi lié à http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html qui dit

    import (disponible uniquement dans Maven 2.0.9 ou plus tard)

    Ce champ n'est utilisé que sur une dépendance de type pom dans le <dependencyManagement> section. Il indique que les POM doivent être remplacés par les dépendances dans cette POM section. Depuis, ils sont remplacés, dépendances avec un périmètre d'importation ne sont pas réellement participer à la limitation de la transitivité d'une dépendance.

    Je pense c'est à dire, "de prendre toutes les dépendances de ce projet et en ligne dans ce <dependencyManagement> section." Quelqu'un me corrige si je me trompe.

    • Oui, c'était ambigu. Ce que je voulais dire (pour fourni) " j'ai les dépendances sur ma machine en ce moment, en train de les utiliser. Mais quand vous construisez le paquet, ne vous inquiétez pas, parce que la machine que je vais exécuter ce code sur la volonté d'avoir les dépendances et ont le classpath réglé de manière appropriée'. C'est la même chose que vous dites, non?
    • Sont système de dépendance ajouté au classpath ?
    • oui, sinon, à quoi servirait-il de même en précisant eux? Quel est l'effet pourraient-ils avoir?
    InformationsquelleAutor Daniel Kaplan
  2. 18

    Veuillez trouver la signification exacte de ces étendues dans Maven

    J'ai appelé Maven http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

    Dépendance champ est utilisé pour limiter la transitivité d'une dépendance, ce qui modifie également le classpath utilisé pour divers construire des tâches.

    Il y a 6 étendues disponibles:

    • compiler:

      C'est l'étendue par défaut, utilisé si aucun n'est spécifié. Compiler les dépendances sont disponibles dans tous les chemins de classe d'un projet. En outre, ces dépendances sont propagées à projets dépendants.

    • fourni:

      C'est un peu comme de la compilation, mais indique que vous attendez le JDK ou un conteneur de fournir la dépendance au moment de l'exécution. Par exemple, lors de la construction d'une application web pour le Java Enterprise Edition, vous devez définir la dépendance sur l'API Servlet et liées à Java EE Api de marge de manœuvre car le conteneur web fournit ces classes. Ce champ d'application est uniquement disponible sur la compilation et de test classpath, et n'est pas transitive.

    • runtime:

      Ce champ indique que la dépendance n'est pas requis pour la compilation, mais c'est pour l'exécution. C'est dans le moteur d'exécution et de tester les chemins de classe, mais pas le compiler classpath.

    • test:

      Ce champ indique que la dépendance n'est pas nécessaire pour l'utilisation normale de l'application, et n'est disponible que pour le test de compilation et d'exécution des phases.

    • système:

      De ce champ d'application est similaire sauf que vous devez fournir le BOCAL qui contient explicitement. L'artefact est toujours disponible et n'est pas recherché dans un référentiel.

    • import (disponible uniquement dans Maven 2.0.9 ou plus tard):

      Ce champ n'est utilisé que sur une dépendance de type pom dans la section. Il indique que les POM doivent être remplacés par les dépendances dans cette POM section. Depuis, ils sont remplacés, dépendances avec un périmètre d'importation ne sont pas réellement participer à la limitation de la transitivité d'une dépendance.

    • Citant tout simplement la doc n'est pas vraiment utile ici. C'est une question compliquée qui pourrait utiliser quelques explications et exemples au-delà de la simple phrase ou deux de la doc.
    InformationsquelleAutor Pavan