Gradle : Rendre un jar tiers disponible dans le dépôt gradle local

Question

Actuellement, je teste Gradle comme alternative à Maven. Dans mes projets, il y a quelques jars tiers qui ne sont pas disponibles dans les dépôts (Maven). Mon problème est maintenant de savoir comment je peux installer ces jars dans mon dépôt local .gradle. (Si c'est possible, je ne veux pas utiliser le dépôt Maven local, car Gradle doit fonctionner indépendamment). En ce moment, je reçois beaucoup d'exceptions à cause de jars manquants. Dans Maven, c'est assez simple en exécutant la commande install. Cependant, ma recherche sur Google pour quelque chose de similaire à la commande install de Maven n'a pas abouti. Quelqu'un a-t-il une idée ?

Answer 1

Vous pouvez inclure les dépendances JAR de votre système de fichiers comme :

dependencies {
    runtime files('libs/a.jar', 'libs/b.jar')
    runtime fileTree(dir: 'libs', include: '*.jar')
}

vous pouvez changer le temps d'exécution pour compiler/tester/compiler/etc..

Answer 2

Une réponse plus complète a été donnée sur une liste de diffusion par Adam Murdoch à l'adresse suivante http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html

En avril 2010, il n'existait pas de moyen simple d'ajouter un nouveau fichier jarfile à votre dépôt ~/.gradle. Je cherche actuellement à savoir si cela a changé.

Answer 3

J'ai utilisé l'option (1) de l'article d'Adam Murdoch (déjà lié ci-dessus) : http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html ) avec gradle-1.3 et cela fonctionne très bien !

Voici son commentaire :

1. Copiez les jars dans un répertoire local et utilisez un référentiel flatDir() pour les utiliser à partir de là. Par exemple, vous pouvez les copier dans $projectDir/lib et dans votre fichier de construction faire :

dépôts { flatDir(dirs : 'lib') }

Les fichiers du répertoire lib doivent respecter le schéma de dénomination : nom-version-classifieur.extension, où la version et le classifieur sont facultatifs. Ainsi, par exemple, vous pouvez les appeler groovy-1.7.0.jar ou même groovy.jar

Ensuite, il suffit de déclarer les dépendances comme d'habitude :

dépendances { compilez 'groovy:groovy:1.7.0' }

Il y a un peu plus de détails sur le dépôt de flatDir() : http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sec:flat_dir_resolver

1. Similaire à la méthode ci-dessus, mais en utilisant un résolveur ivy au lieu de flatDir(). C'est à peu près la même chose que ci-dessus, mais cela permet beaucoup plus d'options en ce qui concerne les noms et les emplacements.

Il y a des détails à ce sujet : http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sub:more_about_ivy_resolvers

1. Ne vous embêtez pas à déclarer les dépendances. Copiez simplement les jars dans un répertoire local quelque part et ajoutez une dépendance de fichier. Par exemple, si les jars sont dans $projectDir/lib :

dépendances { compile fileTree('lib') // ceci inclut tous les fichiers sous 'lib' dans le classpath de la compilation }

Plus de détails à l'adresse suivante http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#N12EAD

1. Utilisez maven install pour installer les dépendances dans votre cache maven local, et utilisez le cache maven comme dépôt :

repositories { mavenRepo(urls : new File(System.properties['user.home'], '.m2/repository').toURI().toURL())) }

Answer 4

Peut-être que quelque chose m'échappe à la lecture de votre question, en supposant que votre repo gradle est du type flatDir, vous devriez pouvoir y copier les fichiers sous la forme myjar-1.0.jar et les résoudre comme myjar de version 1.0.

Je ne vois pas pourquoi il serait nécessaire pour Gradle d'exécuter maven pour accéder à un dépôt local de maven. Vous pouvez simplement définir les dépôts maven et il devrait résoudre les dépendances. Vous pouvez utiliser gradle upload pour pousser les jars des dépôts maven locaux ou distants si vous en avez besoin. Dans ce cas, il exécutera maven.

Answer 5

Une manière totalement différente de penser à ce type de problème, surtout s'il se produit souvent, est d'utiliser un gestionnaire de référentiel. Il existe d'excellentes options open source telles que Artifactory, Nexus ou Archiva.

Supposons que vous ayez un fichier jar d'origine douteuse qui doit être inclus dans votre compilation jusqu'à ce que vous ayez la possibilité de le remanier. Un gestionnaire de référentiel vous permettrait de télécharger le fichier dans votre propre référentiel sous le nom, pour les besoins de cet exemple, de dubious-origin-UNKNOWN.jar.

Alors votre build.gradle ressemblerait à quelque chose comme ceci :

repositories {
    mavenRepo urls: "http://your.own.repository/url";
}

dependencies {
    compile "dubious:origin:UNKNOWN";
}

L'utilisation d'un gestionnaire de référentiel présente de nombreux autres avantages, tels que la mise en cache d'artefacts distants, la suppression d'artefacts de scm, la mise à disposition de versions, des autorisations d'utilisateur plus granulaires, etc.

D'un autre côté, vous ajouteriez un serveur qui nécessite une certaine maintenance pour assurer le fonctionnement de vos constructions.

Cela dépend de la taille de votre projet, je suppose.