79 votes

JDK tools.jar comme dépendance de maven

Je voudrais mettre JDK tools.jar comme dépendance de compilation. J'ai trouvé quelques exemples qui indiquent d'utiliser le systemPath comme suit :

<dependency>
  <groupId>com.sun</groupId>
  <artifactId>tools</artifactId>
  <scope>system</scope>
  <systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>

Le problème est que le chemin n'est pas correct pour Mac Os X (mais il l'est pour Windows et Linux). Pour lui, le chemin correct est ${java.home}/../Classes/classes.jar .

Je cherche un moyen de définir une propriété maven de telle sorte que si le système est détecté comme étant Mac Os X, la valeur est fixée à ${java.home}/../Classes/classes.jar sinon, elle est fixée à vers ${java.home}/../lib/tools.jar (comme il est possible de le faire avec ANT). Quelqu'un a-t-il une idée ?

0 votes

0 votes

@user7610 Il ne s'agit pas d'un doublon, cette question traite de la situation pré-Java 9. Le duplicata que vous suggérez traite de la situation post-Java 9.

47voto

sblundy Points 27163

C'est à cela que servent les profils : extraire le chemin d'accès à une propriété, configurer des profils pour Windows, OSX, etc. et définir les valeurs de la propriété de manière appropriée.

Voici la page de documentation qui traite des profils pour les systèmes d'exploitation : Modèle de paramètres locaux de Maven

Cela devrait ressembler à quelque chose comme ça :

  <profiles>
    <profile>
      <id>windows_profile</id>
      <activation>
        <os>
          <family>Windows</family>
        </os>
      </activation>
      <properties>
        <toolsjar>${java.home}/../lib/tools.jar</toolsjar>
      </properties>
    </profile>
    <profile>
      <id>osx_profile</id>
      <activation>
        <os>
          <family>mac</family>
        </os>
      </activation>
      <properties>
        <toolsjar>${java.home}/../Classes/classes.jar</toolsjar>
      </properties>
    </profile>
  </profiles>

0 votes

J'utilise OS X 10.7 (Lion) et cela a fonctionné pour moi, sauf que le truc marrant était que j'avais déjà un profil *nix pour les boîtes linux (<famille>unix</famille>). Avec ces deux profils là, il ignorait mon profil pour <family>mac</family>. Je pouvais donc soit modifier le chemin d'accès de l'entrée du profil *nix, soit commenter le profil de ce profil pour qu'il voie mon profil pour <family>mac</family>.

3 votes

Si vous devez prendre en charge à la fois Apple Java 6 ( Classes/classes.jar ) et Oracle Java 7 ( lib/tools.jar ) sous OS X, cela ne fonctionnera pas, mais la réponse de @Laurent le fera.

1 votes

stackoverflow.com/a/29585979 Il semble que la réponse soit meilleure pour JDK 1.7, JDK 1.8 et El Capitan pour moi.

40voto

Laurent Points 1002

Merci de m'avoir présenté les profils maven.

J'ai utilisé le profil comme mentionné ci-dessus et en activant un profil basé sur la présence du fichier désiré :

<profiles>
    <profile>
        <id>default-profile</id>
        <activation>
            <activeByDefault>true</activeByDefault>
            <file>
                <exists>${java.home}/../lib/tools.jar</exists>
            </file>
        </activation>
        <properties>
            <toolsjar>${java.home}/../lib/tools.jar</toolsjar>
        </properties>
    </profile>
    <profile>
        <id>mac-profile</id>
        <activation>
            <activeByDefault>false</activeByDefault>
            <file>
                <exists>${java.home}/../Classes/classes.jar</exists>
            </file>
        </activation>
        <properties>
            <toolsjar>${java.home}/../Classes/classes.jar</toolsjar>
        </properties>
    </profile>
</profiles>

J'ai posté cette réponse pour souligner une erreur dans le post précédent : la section des propriétés ne peut être utilisée dans la section d'activation que pour activer un profil en fonction de l'existence de la propriété spécifiée. Pour définir une propriété, la section propriétés doit être utilisée comme ci-dessus.

0 votes

L'avantage de la vérification de l'existence de classes.jar est qu'elle permet d'utiliser tools.jar sur la plateforme Mac. Cela pourrait être important pour les futures versions d'OpenJDK sur Mac ( lien ) car il aurait probablement un tools.jar et non un classes.jar.

0 votes

+1 parce que cela teste le fichier réel que nous recherchons et ne dépend pas de la détection du système d'exploitation (qui n'est pas nécessaire de toute façon).

0 votes

Plus près, mais stackoverflow.com/a/29585979 était une meilleure solution au final (pour JDK 1.7/1.8 et El Capitan) au moins.

9voto

Jianyu Points 131

Bonjour, je sais que vous êtes tous intelligents, mais il m'a fallu quelques jours pour comprendre que la réponse n'est pas complète - le profil et la dépendance sont tous deux nécessaires. J'espère que personne ne perdra plus de temps sur ce sujet. Veuillez voir mon code complet ci-dessous :

<profiles>
    <profile>
        <id>osx_profile</id>
        <activation>
            <activeByDefault>false</activeByDefault>
            <os>
                <family>mac</family>
            </os>
        </activation>
        <properties>
            <toolsjar>${java.home}/../Classes/classes.jar</toolsjar>
        </properties>
        <dependencies>
            <dependency>
                <groupId>com.sun</groupId>
                <artifactId>tools</artifactId>
                <version>1.6.0</version>
                <scope>system</scope>
                <systemPath>${toolsjar}</systemPath>
            </dependency>
        </dependencies>
    </profile>
</profiles>

2 votes

El dependencies à l'intérieur du profil n'est pas nécessaire. Il suffit de le déclarer, une fois, à l'extérieur du profil et de faire en sorte que les profils déterminent la valeur correcte de l'indicateur d'accessibilité. toolsjar propriété.

1 votes

Cette dépendance n'est nécessaire que pour mac, il est préférable de ne la déclarer que dans ce profil.

0 votes

La ligne ne devrait-elle pas <toolsjar>${java.home}/../Classes/classes.jar</toolsjar> plutôt être <toolsjar>${java.home}/../lib/tools.jar</toolsjar> ?

7voto

Animesh Sharma Points 2045

D'une manière ou d'une autre, l'éclipse sous Windows ne parvient pas à détecter {java.home}. J'ai donc dû définir JAVA_HOME au lieu de java.home. JAVA_HOME a été défini dans Run->Run Configurations->Environment. Cela a fonctionné pour moi avec le JDK standard (pas le JDK d'Apple).

<profiles>
        <profile>
            <id>windows-profile</id>
            <activation>
                <activeByDefault>true</activeByDefault>
                <file>
                    <exists>${JAVA_HOME}/lib/tools.jar</exists>
                </file>
            </activation>
            <properties>
                <toolsjar>${JAVA_HOME}/lib/tools.jar</toolsjar>
            </properties>
        </profile>
        <profile>
            <id>mac-profile</id>
            <activation>
                <activeByDefault>false</activeByDefault>
                <file>
                    <exists>${java.home}/../lib/tools.jar</exists>
                </file>
            </activation>
            <properties>
                <toolsjar>${java.home}/../lib/tools.jar</toolsjar>
            </properties>
        </profile>
    </profiles>

    <dependencies>
        <dependency>
                <groupId>jdk.tools</groupId>
                <artifactId>jdk.tools</artifactId>
                <version>jdk1.8.0</version>
                <scope>system</scope>
                <systemPath>${toolsjar}</systemPath>
            </dependency>
        </dependencies>

7voto

user1047788 Points 80

J'ai trouvé une solution dans Q : Déclarer une dépendance maven sur tools.jar pour travailler sur JDK 9

Comme la magie de maven est assez élaborée, surprenante pour les nouveaux venus et un sujet d'améliorations futures, il est préférable de ne pas faire de copier-coller. Ce module existe donc pour que vous n'ayez pas à connaître ou à vous soucier des détails. ~~ https://github.com/olivergondza/maven-jdk-tools-wrapper

<dependency>
  <groupId>com.github.olivergondza</groupId>
  <artifactId>maven-jdk-tools-wrapper</artifactId>
  <version>0.1</version>
</dependency>

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X