web-dev-qa-db-fra.com

Gradle: rendre un pot tiers disponible pour le référentiel local Gradle

actuellement, je teste Gradle comme une alternative à Maven. Dans mes projets, il existe des pots tiers, qui ne sont disponibles dans aucun référentiel (Maven). Mon problème est maintenant, comment pourrais-je le gérer pour installer ces pots dans mon référentiel local .gradle. (Si c'est possible, je ne veux pas utiliser le référentiel Maven local, car Gradle devrait fonctionner indépendamment.) Pour le moment, je reçois beaucoup d'exceptions en raison de pots manquants. Dans Maven, c'est assez simple en exécutant la commande install. Cependant, ma recherche Google pour quelque chose de similaire à la commande d'installation de Maven n'a pas réussi. Quelqu'un a-t-il une idée?

maven-2jarrepositoryinstallgradle
44
MH.

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 runtime pour compile/testCompile/etc ..

39
tolitius

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

Depuis avril 2010, il n'y avait pas de moyen simple d'ajouter un nouveau fichier jar à votre référentiel ~/.gradle. Recherche actuellement si cela a changé.

Depuis octobre 2014, c'est toujours le cas - parce que gradle fait une somme de contrôle md5 de votre fichier jar, vous ne pouvez pas simplement le télécharger et le placer dans un répertoire sous .gradle/caches, et gradle ne le fait pas, dans la mesure où Je peux dire, avoir des tâches qui vous permettent de prendre un fichier local et de pousser ce fichier dans son cache.

10
Ian Durkan

Option utilisée (1) sur le post 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 ça marche très bien!

Voici son commentaire:

  1. Copiez les fichiers JAR 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 build faire:

référentiels {flatDir (dirs: 'lib')}

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

Ensuite, vous déclarez simplement les dépendances comme normales:

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

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

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

Il y a quelques détails sur: 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 fichiers JAR dans un répertoire local quelque part et ajoutez une dépendance de fichier. Par exemple, si les fichiers JAR sont dans $ projectDir/lib:

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

Plus de détails sur: 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 référentiel:

référentiels {mavenRepo (urls: nouveau fichier (System.properties ['user.home'], '.m2/repository'). toURI (). toURL ())}

8
oae

En bref: déployer vers le gestionnaire de référentiel. Il peut être local, sur le LAN de l'entreprise.

Une manière tout à fait différente de penser à ce type de problème, surtout si cela se produit souvent, consiste à utiliser un gestionnaire de référentiel. Il existe d'excellentes options open source comme Artifactory, Nexus ou Archiva.

Supposons que vous ayez un fichier jar d'une origine douteuse qui doit être inclus dans votre build jusqu'à ce que vous ayez la possibilité de le refactoriser. Un gestionnaire de référentiel vous permettrait de télécharger le fichier vers votre propre référentiel comme, pour cet exemple, dubious-Origin-UNKNOWN.jar

Votre build.gradle ressemblerait alors à 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 des artefacts distants, la suppression des artefacts de scm, les versions intermédiaires, les autorisations utilisateur plus granulaires, etc.

Sur le plan négatif, vous ajouteriez un serveur qui comporte des frais de maintenance pour maintenir vos builds en cours d'exécution.

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

3
MrJohnBBQ

Peut-être qu'il me manque quelque chose dans ma lecture de votre question, en supposant que votre repo gradle soit du type flatDir, vous devriez pouvoir y copier les fichiers sous la forme myjar-1.0.jar et les résoudre comme myjar de la version 1.0.

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

3
sal

Je pense que quelque chose comme ça devrait fonctionner:

dependencies {
  files('yourfile.jar')
}

Est-ce que ça marche pour toi?

1
amorfis