web-dev-qa-db-fra.com

Comment faire pointer le référentiel Gradle vers le répertoire local

Pour une raison quelconque, mon équipe offshore n'est pas en mesure de télécharger les artefacts (dépendances) de mes clients Artifactory qui est le référentiel de dépendances de nos organisations. "Actualiser les dépendances" ne déclenche rien et donne une TIME OUT EXCEPTION. Je vois que mes "dépendances Gradle" sont téléchargées à l'emplacement "D: /C813507/Gradle/gradle-1.11/bin/caches/modules-2/files-2.1/". Puis-je compresser ce dossier et y envoyer? Comment implémentent-ils quelque chose dans gradle qui pointe vers leur répertoire local. Mon gradle de construction a la ligne suivante. Comment pointer l'URL vers le répertoire local dans le système d'exploitation Windows

repositories {
         maven {
            url 'http://artifactory.myorg.com:8081/artifactory/plugins-release'
        }

}
mavengradlebuild.gradle
17
Vinodh Thiagarajan

Si vous ne pouvez pas donner accès à votre équipe offshore, vous pouvez copier tous les fichiers de dépendances nécessaires dans un seul répertoire, puis utiliser le référentiel flatDir.

repositories {
   flatDir {
       dirs 'D:/path/to/local/directory'
   }
}


dependencies {
   compile name: 'name-of-jar'
}

Une autre façon sans utiliser le référentiel flatDir est:

dependencies {
    compile files('/path/to/dir/something_local.jar')
}
27
dieend

Au lieu de configurer le référentiel flatDir, vous pouvez déclarer un référentiel maven local comme suit:

repositories {
   maven {
       url 'file://D:/path/to/local/directory'
   }
}

Comme @ Peter Niederwieser mentionné, le référentiel flatDir ne prend pas en charge la résolution des dépendances transitives. maven le dépôt local le fait.

18
Alex Lipov

Utiliser flatDir comme ci-dessous est une option:

repositories {
   flatDir {
       dirs 'D:/path/to/local/directory'
   }
}

Cela marche. Mais s'il existe mavenCentral () ou d'autres référentiels maven qui contiennent le même JAR, la priorité sera donnée au référentiel maven sur flatDir.

Extrait de la documentation Gradle: https://docs.gradle.org/current/userguide/repository_types.html

Gradle va générer dynamiquement un descripteur de module (sans aucune information de dépendance) basé sur la présence d'artefacts. Cependant, comme Gradle préfère utiliser des modules dont le descripteur a été créé à partir de métadonnées réelles plutôt que d'être généré, les référentiels de répertoires plats ne peuvent pas être utilisés pour remplacer les artefacts par des métadonnées réelles d'autres référentiels. Par exemple, si Gradle ne trouve que jmxri-1.2.1.jar dans un référentiel de répertoire plat, mais jmxri-1.2.1.pom dans un autre référentiel qui prend en charge les métadonnées, il utilisera le deuxième référentiel pour fournir le module.

Donc flatDir n'est pas bon. Nous devons utiliser le référentiel maven local comme mentionné dans la deuxième réponse. Mais il y a quelques problèmes avec la deuxième réponse

  1. Pas portable
  2. Si l'artefact est également présent dans les dépôts mondiaux, il n'est pas clair d'où il sera choisi.

Nous pouvons résoudre ces problèmes en utilisant une solution comme ci-dessous:

  1. Créez un dossier appelé libs dans le répertoire du projet
  2. Copiez vos artefacts dans ce répertoire libs (si vous utilisez git ou tout autre scm, assurez-vous de distribuer ce libraire fdler afin que les autres puissent simplement gradle build sans aucun problème)
  3. Déclarez un dépôt maven dans votre répertoire libs et appelez mavenLocal () avant de lister tout autre repos. Cette étape est très importante pour vous assurer que le bocal est choisi dans votre répertoire local plutôt que dans les autres référentiels globaux
repositories {
   maven {
       url uri("${projectDir}/libs")
   }

   mavenLocal()
   <All your Repos here>
   mavenCentral()
}

De cette façon, vous pouvez être sûr que même si le JAR est présent dans d'autres référentiels, il ne sera choisi que dans votre répertoire local et la solution est également portable.

0
mk..