web-dev-qa-db-fra.com

bash: jar: commande introuvable

J'utilise Jenkins pour déployer la build.

Nous devons extraire des fichiers d'un . War dans un répertoire. Nous avons un fichier . Xml qui inclut des commandes pour extraire les fichiers du fichier . War et démarrer le serveur.

La génération est créée correctement mais l'extraction . War ne se produit pas et le dossier de destination est laissé vide. La console Jenkins affiche la sortie suivante:

[sshexec] bash: jar: command not found

Comme lu dans d'autres réponses, j'ai correctement défini le PATH dans . Bashrc ou dans . Profile mais je suis toujours confronté au même problème.

javabashjenkins
10
Satish

Installez Java développez comme suit:

 yum install Java-devel
20
Smartop

Pour être précis, le répertoire bin Java n'est pas dans votre variable PATH. Ajoutez-le à la variable PATH. Afin de rechercher les exécutables, le système d'exploitation doit avoir une liste de répertoires à rechercher. Donc, ajoutez le répertoire qui contient la variable d'environnement 'jar tool in the PATH`

Remarque: pour Windows, le séparateur de chemin est (;) Et pour un système d'exploitation de type Unix, le séparateur de chemin est (:)

3
Keerthivasan

Le "[sshexec]" m'indique que vous utilisez un plugin Jenkins pour exécuter une commande sur un hôte distant.

Cela signifie généralement que Jenkins exécute ceci (ou une chose équivalente en implémentant le protocole SSH nativement):

ssh user@remotehost 'jar arg1 arg2...'

Ce qui se passe ici, c'est que le démon sshd sur l'hôte distant exécutera le shell par défaut de l'utilisateur et demandera au shell d'exécuter la ligne de commande. Le shell n'est généralement pas exécuté en tant que "shell de connexion", ce qui signifie qu'il ignorera les étapes d'initialisation que les shells de connexion effectuent normalement lorsque l'utilisateur se connecte de manière interactive.

Vous pouvez étudier man (name of your Shell) pour voir exactement quelle est la différence entre un Shell exécuté avec l'option -l Et un exécuté sans lui. Dans le cas de bash, cela signifie essentiellement que .profile Et .bashrc Ne seront pas exécutés, donc aucune modification de PATH que vous pourriez y avoir n'aura lieu.

Je pense que votre meilleur pari est de fournir le chemin d'accès complet à la commande jar lorsque vous voulez l'exécuter.

2
sti

Au fur et à mesure que vous exécutez la commande sur l'hôte distant, il invoquera le nouveau shell sur l'hôte distant. Le CHEMIN que vous avez défini dans le fichier Host .bashrc actuel ne fera aucune différence. Au lieu de cela, si vous définissez le CHEMIN pour Java dans .bashrc de l'hôte distant, les choses devraient fonctionner autrement si vous exécutez un script, puis mentionnez le chemin complet du JAR comme /usr/jdk64/jdk1.8.0_40/ bin/jar -tf /tmp/jars/abc.jar lors de l'appel de la commande sur l'hôte distant.

Deux façons de procéder:

  1. export PATH = $ PATH: /usr/jdk64/jdk1.8.0_40/bin ---> dans le .bashrc de l'hôte distant

  2. /usr/jdk64/jdk1.8.0_40/bin/jar -tf /tmp/jars/abc.jar -> appeler la commande jar avec le chemin complet du JAR depuis l'hôte distant.

0
Ajit K'sagar