comment exporter un fichier jar exécutable dans gradle, et ce fichier peut s’exécuter tel quel avec les bibliothèques de référence

comment exporter un fichier jar exécutable dans gradle, et ce fichier jar peut s’exécuter comme il inclut des bibliothèques de référence.

build.gradle

apply plugin: 'java' manifest.mainAtsortingbutes("Main-Class" : "com.botwave.analysis.LogAnalyzer") repositories { mavenCentral() } dependencies { comstack ( 'commons-codec:commons-codec:1.6', 'commons-logging:commons-logging:1.1.1', 'org.apache.httpcomponents:httpclient:4.2.1', 'org.apache.httpcomponents:httpclient:4.2.1', 'org.apache.httpcomponents:httpcore:4.2.1', 'org.apache.httpcomponents:httpmime:4.2.1', 'ch.qos.logback:logback-classic:1.0.6', 'ch.qos.logback:logback-core:1.0.6', 'org.slf4j:slf4j-api:1.6.0', 'junit:junit:4.+' ) } 

après je cours: gradle build

il crée le dossier de compilation et j’exécute le fichier jar dans build / libs / XXX.jar:

java -jar build / libs / XXX.jar

voici une exécution dit:

 Exception in thread "main" java.lang.NoClassDefFoundError: ch/qos/logback/core/joran/spi/JoranException 

comment puis-je l’exécuter avec les bibliothèques de référence?

Vous pouvez y parvenir avec le plugin d’application Gradle

J’espère que cela aide quelqu’un (car j’ai malheureusement passé pas mal de temps à essayer de trouver la solution). Voici la solution qui a fonctionné pour moi pour créer un fichier JAR exécutable. J’intègre Jetty dans la méthode principale, Jetty 9 étant spécifique et utilisant Gradle 2.1.

Incluez le code suivant dans votre fichier build.gradle (si un sous-projet est le projet “principal” dont le fichier JAR doit être construit, ajoutez-le au sous-projet qui doit démarrer comme ce projet (‘:’) {insérez le code quelque part ici, après des dépendances.}.

De plus, vous devez append le plugin java pour que cela fonctionne: appliquez le plugin: ‘java’.

Ma tâche jar se présente comme suit:

 apply plugin: 'java' jar { archiveName = "yourjar.jar" from { configurations.runtime.collect { it.isDirectory() ? it : zipTree(it) } configurations.comstack.collect { it.isDirectory() ? it : zipTree(it) } } manifest { atsortingbutes 'Main-Class': 'your.package.name.Mainclassname' } exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' } 

Et puis vous pouvez exécuter votre yourjar.jar via la ligne de commande:

 java -jar yourjar.jar 

Les META-INF / .RSA, META-INF / .SF et META-INF / *. DSA doivent être exclus pour que cela fonctionne. Sinon, une exception SecurityException est lancée.

Le problème semble être lié à Jetty intégré, car Jetty a migré vers Eclipse et signe maintenant ses JAR, ce qui, à mon avis, devient problématique lorsque d’autres fichiers JAR non signés veulent charger les fichiers JAR signés. S’il vous plaît n’hésitez pas à m’éduquer si je me trompe en ceci, c’est juste ce que je lis.

Les JAR dont dépend le projet sont définis dans les dépendances comme suit:

 dependencies { // add the subprojects / modules that this depends on comstack project(':subproject-1') comstack project(':subproject-2') comstack group: 'org.eclipse.jetty', name: 'jetty-server', version: '9.2.6.v20141205' comstack group: 'org.eclipse.jetty', name: 'jetty-servlet', version: '9.2.6.v20141205' comstack group: 'org.eclipse.jetty', name: 'jetty-http', version: '9.2.6.v20141205' } 

EDIT: Avant, au lieu de juste

 configurations.runtime.collect{...} 

j’avais

 configurations.runtime.asFileTree.files.collect{...} 

Cela a provoqué un comportement étrange dans un projet plus important en construction propre. Lors de la première exécution du fichier jar après l’exécution de la commande cleanle clean (après le nettoyage manuel du répertoire de construction), une exception NoClassDefFoundException (dans notre projet avec de nombreux sous-projets) serait lancée. vider le répertoire de construction manuellement), pour une raison quelconque, il avait toutes les dépendances. Cela ne s’est pas produit si asFileTree.files a été omis.

Je devrais également noter que toutes les dépendances de compilation sont incluses dans le runtime, mais que tous les runtime ne sont pas inclus dans la compilation. Donc, si vous utilisez juste comstackr

  configurations.comstack.collect { it.isDirectory() ? it : zipTree(it) } 

Ensuite, n’oubliez pas que si une exception NoClassDefFoundException est émise, certaines classes ne sont pas trouvées à l’exécution, ce qui signifie que vous devez également inclure ceci:

  configurations.runtime.collect { it.isDirectory() ? it : zipTree(it) } 

Réponse rapide

  1. Ajoutez ce qui suit à votre build.gradle :

     apply plugin: 'application' mainClassName = 'org.example.app.MainClass' jar { manifest { atsortingbutes 'Main-Class': mainClassName, 'Class-Path': configurations.runtime.files.collect {"$it.name"}.join(' ') } } 
  2. À partir du répertoire du projet, exécutez gradle installDist
  3. Exécutez java -jar build/install//lib/.jar

Je recommande également d’append la version de l’application à votre build.gradle , mais ce n’est pas obligatoire. Si vous le faites, le nom du -.jar jar sera -.jar .

Note: j’utilise gradle 2.5


Détails

Pour créer un fichier exécutable autonome que vous pouvez simplement exécuter avec:

 java -jar appname.jar 

Tu auras besoin de:

  1. votre pot pour inclure un fichier MANIFEST pointant vers la classe principale de votre application
  2. toutes vos dépendances (classes de jars en dehors de votre application) à inclure ou à accéder d’une manière ou d’une autre
  3. votre fichier MANIFEST pour inclure le classpath correct

Comme d’autres réponses l’indiquent, vous pouvez utiliser un plug-in tiers pour y parvenir, comme shadow ou one-jar .

J’ai essayé l’ombre, mais je n’aimais pas le fait que toutes mes dépendances et leurs ressources étaient jetées à plat dans le fichier jar avec mon code d’application. Je préfère également minimiser l’utilisation de plug-ins externes.

Une autre option consisterait à utiliser le plug-in d’application Gradle comme @erdi a répondu ci-dessus. En gradle build , vous construirez un gradle build pour vous et le regrouperez avec toutes vos dépendances dans un fichier zip / tar. Vous pouvez également exécuter gradle installDist pour ignorer la compression.

Cependant , comme @jeremyjjbrown a écrit dans un commentaire, le plug in ne crée pas de fichier exécutable en soi. Il crée un jar et un script qui construit le classpath et exécute une commande pour exécuter la classe principale de votre application. Vous ne pourrez pas exécuter java -jar appname.jar .

Pour obtenir le meilleur des deux mondes, suivez les étapes ci-dessus qui créent votre fichier jar avec toutes vos dépendances sous forme de fichiers séparés et ajoutez les valeurs correctes à votre fichier MANIEST.

Toutes ces réponses sont erronées ou obsolètes.

L’OP demande ce qu’on appelle un “gros pot”. C’est un jar exquis qui contient toutes les dépendances de sorte qu’il ne nécessite aucune dépendance extérieure pour pouvoir fonctionner (sauf pour un JRE bien sûr!).

La réponse au moment de l’écriture est le plugin Gradle Shadow Jar, expliqué assez clairement dans Shadow Plugin User Guide & Examples .

J’ai lutté un peu. Mais cela fonctionne:

mettez toutes ces lignes quelque part dans votre fichier build.gradle (je les place près du haut):

 buildscript { repositories { jcenter() } dependencies { classpath 'com.github.jengelman.gradle.plugins:shadow:1.2.4' } } apply plugin: 'com.github.johnrengelman.shadow' shadowJar { baseName = 'shadow' classifier = null version = null } jar { manifest { atsortingbutes 'Class-Path': '/libs/a.jar' atsortingbutes 'Main-Class': 'core.MyClassContainingMainMethod' } } 

PS: ne vous inquiétez pas des “repositorys”, “dépendances” ou “plug-ins” ailleurs dans votre fichier de construction et laissez les lignes à l’intérieur de ce bloc “buildscript” (je n’ai aucune idée de ce que vous devez faire) cette).

PPS le Guide de l’utilisateur et les exemples du plugin Shadow est bien écrit mais ne vous dit pas d’inclure la ligne

 atsortingbutes 'Main-Class': 'core.MyClassContainingMainMethod' 

où je l’ai mis ci-dessus. Peut-être parce que l’auteur suppose que vous êtes moins ignorant que moi, et vous le faites probablement. Je ne sais pas pourquoi on nous dit de mettre un atsortingbut “Class-Path” étrange, mais si ce n’est pas cassé, ne le réparez pas.

Quand tu vas alors

 > gradle shadowjar 

Avec un peu de chance, Gradle construira un gros fichier exécutable sous / build / libs (nom par défaut “shadow.jar”) que vous pouvez exécuter en faisant ceci:

 > java -jar shadow.jar 

J’ai vérifié quelques liens pour la solution, et finalement les étapes mentionnées ci-dessous pour le faire fonctionner. J’utilise Gradle 2.9.

Apportez les modifications suivantes dans votre fichier de construction:

1. Mentionnez le plugin:

 apply plugin: 'eu.appsatori.fatjar' 

2. Fournissez le buildscript:

 buildscript { repositories { jcenter() } dependencies { classpath "eu.appsatori:gradle-fatjar-plugin:0.3" } } 

3. Fournir la classe principale:

 fatJar { classifier 'fat' manifest { atsortingbutes 'Main-Class': 'my.project.core.MyMainClass' } exclude 'META-INF/*.DSA', 'META-INF/*.RSA', 'META-INF/*.SF' } 

4. Créez le fatjar:

 ./gradlew clean fatjar 

5. Exécutez le fatjar à partir de / build / libs /:

 java -jar MyFatJar.jar