J'ai un exemple de projet, avec la configuration suivante:
/root
+ Pure Java Lib
+ Android Test Lib
+ Android Test Project
Où le ' Test Project ' dépend du ' Test Lib ' , et le dernier dépend du ' Pure Java Lib ' Compiler le projet et lancer cette configuration marche à merveille .
Je songe maintenant à importer mon ancien espace de travail Eclipse et à travailler avec Android studio, le problème est que la configuration du projet est différente et que je souhaite le conserver de cette façon.
par exemple si utiliser l'exemple précédent:
/root
+ Android Test Lib
+ Android Test Project
/Some Other folder (another repository for example)
+ Pure Java Lib
J'ai essayé de nombreuses configurations, mais je n'ai pas trouvé de moyen de référencer un projet hors de la portée du dossier parent (' root ' dans le répertoire exemple de cas).
Sur de nombreuses plates-formes/modules, vous pouvez utiliser l'option '..' pour vous déplacer dans les dossiers, mais cela n'a pas fonctionné pour moi. Je l'ai peut-être mal utilisé.
Est-ce que quelqu'un sait comment cela peut être réalisé avec Gradle?
UPDATE
Je vais essayer d'être plus générique:
/C:/
/Project A
+ Module 1 - Pure Java
+ Module 2 - Android Test Lib
+ Module 3 - Android Test Project
/Project B
+ Module 1 - Pure Java
+ Module 2 - Pure Java
+ Module 3 - Pure Java
Je voudrais utiliser le module 1 de projet B, dans le projet A.
PDATE: 09-03-19
Je le vois maintenant et je dois mettre à jour ... après presque 6 ans, je suis aujourd'hui plus sage et je peux certainement affirmer que le problème était que je ne comprenais pas le concept de "source de la vérité".
Bien qu’avoir une référence à une bibliothèque soit un concept agréable à avoir .. et peut sembler être une "source de vérité", la VRAIE "source de vérité" serait la version du code que chaque projet utilise de cette bibliothèque, car la bibliothèque elle-même a des versions .. plusieurs versions et la "Source de vérité" est relative au projet qui utilise la bibliothèque.
La bonne façon serait d’utiliser ce que la plupart des développeurs n’aiment pas, à savoir les sous-modules git, et oui, dupliquer les sources de chaque projet crée le plus de chances que chaque projet utilise une version différente du code.
Cependant, vous devez viser tous vos projets à utiliser la version la plus récente et la plus performante de toutes vos bibliothèques. Ce qui est un défi en soi
La raison pour laquelle c'est la bonne façon de développer un projet avec des sources de bibliothèque est que cela permet de faire évoluer ... vous pouvez avoir des centaines de projets, chacun avec sa propre configuration de bibliothèque.
En supposant que Some Other Folder soit un projet dégradé, vous pouvez ajouter les éléments suivants à votre fichier settings.gradle:
include ':module1'
project(':module1').projectDir = new File(settingsDir, '../Project B/Module 1')
Vous devez mettre dans votre fichier settings.gradle ces lignes:
include ':module2'
project(':module2').projectDir = new File(settingsDir, '../Project 2/Module2')
Ensuite, vous devez ajouter dans votre builde.gradle (Module: app) dans les dépendances , cette ligne:
compile project(':module2')
ou allez dans la structure du projet > app > Dépendances , cliquez sur Ajouter , choisissez 3 dépendances du module et sélectionnez votre module
Avec Gradle 1.10 (je ne sais pas pour quelles autres versions cela sera valable), c’est ce que j’ai trouvé à partir d’une réponse donnée ici http://forums.gradle.org/gradle/topics/reference_external_project_as_dependancy
J'ai un projet de bibliothèque api, un projet de bibliothèque commune et le projet principal de l'application. Chacune est un projet de développement autonome et les deux bibliothèques doivent être partagées entre plusieurs applications.
Dans settings.gradle pour le projet commun:
def apiLibDir = file('../Android-api/Android-api-lib')
def rootProjectDescriptor = settings.rootProject
settings.createProjectDescriptor(rootProjectDescriptor, 'Android-api-lib', apiLibDir)
include ':Android-api-lib'
Ensuite, dans le projet principal de l'application, settings.gradle:
def apiLibDir = file('../Android-libs/Android-api/Android-api-lib')
def rootProjectDescriptor = settings.rootProject
settings.createProjectDescriptor(rootProjectDescriptor, 'Android-api-lib', apiLibDir)
include ':Android-api-lib'
def commonLibDir = file('../Android-libs/Android-common/Android-common-lib')
settings.createProjectDescriptor(rootProjectDescriptor, 'Android-common-lib', commonLibDir)
include ':Android-common-lib'
Dans chacun des fichiers build.gradle respectifs, vous devez simplement les référencer par le nom que vous leur avez donné dans settings.createProjectDescriptor, comme vous le feriez pour toute autre dépendance de projet:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':Android-api-lib')
compile project(':Android-common-lib')
}
Cela semble fonctionner. Cela n'a même pas généré d'erreur pour plusieurs fichiers DEX définissant la bibliothèque api, je suppose que tout cela faisait partie du même processus de construction et que Gradle était assez intelligent pour comprendre tout cela.
Faites un clic droit sur le projet - Sélectionnez "Ouvrir les paramètres du module" - Sélectionnez "Modules" dans le volet de gauche - Cliquez sur le symbole "+" en haut - Choisissez "Importer le module".
Après avoir importé le module. Vous devez l'ajouter en tant que dépendance pour votre projet actuel.
Conservez "Modules" dans le volet gauche et cliquez sur votre projet - Allez maintenant dans l’onglet Dépendances et cliquez sur le symbole "+" situé en bas - Choisissez la troisième option "Modules dépendants" et si vous avez importé votre projet correctement, vous montre tous les modules disponibles qui peuvent être ajoutés en tant que dépendance à votre projet actuel.
Je pose à nouveau cette question d’une manière qui tienne compte des intentions des affiches originales à . Comment référençons-nous les bibliothèques personnalisées Android et Java situées en dehors du répertoire de notre répertoire principal? Projet Android?
Là je réponds à ma propre question. Au cœur de ma réponse, j'utilise @ Ethan (l'auteur de la réponse choisie dans le fil de discussion actuel) pour mieux comprendre le codage en dégradé. Mais ma réponse navigue également dans d'autres pièges et fournit un exemple détaillé étape par étape.