2010-08-24 15 views
1

Je ne sais pas si j'ai totalement mal compris le concept, mais je veux créer plusieurs projets avec des dépendances à d'autres projets qui ne font pas partie de la structure de répertoires d'un projet parent. Je sais que la façon normale de faire cela serait d'utiliser une dépendance externe qui provient d'un référentiel externe. Mais dans ce cas, où disons dans le projet appelé 'F' un cadre est développé, qui est utilisé dans le projet 'P'., Alors P utilise F, mais F ne devrait pas nécessairement être un sous-projet de P comme P est seulement utilisé pour tester le développement de F (mais ce n'est pas seulement un test unitaire). Plus tard dans le processus, lorsque F est stable, F est séparé et peut être consommé par d'autres projets via un référentiel. Mais lors du développement de F avec P comme cas de test, il serait bon que cet aller-retour à travers le référentiel puisse être omis.Can Gradle gère les dépendances locales vers d'autres sous-répertoires?

Pour aggraver le problème, pour le développement initial, il existe plus d'un projet consommateur de test, qui doit tous avoir une dépendance à F, mais pas via un référentiel externe.

Mon idée est de développer F à un endroit sur le disque avec sa propre repositionnement git. Les autres projets P like résident ailleurs sur le disque et ont une dépendance basée sur le système de fichiers local à F. Une telle construction serait-elle possible dans Gradle? Si oui, par où commencer? J'ai analysé les exemples Java mais je n'ai pas trouvé d'exemple approprié.

Des idées?

+0

Pour autant que je peux dire, Gradle ne peut pas gérer l'ajout d'un sous-projet d'une dépendance contenue dans un projet parent, comme le projet racine. Il ne prend en charge que les «projets de pairs» ou les projets côte à côte dans votre hiérarchie et vos projets enfants. Ainsi est la syntaxe: project (': sub-proj1: sub-proj12'). – djangofan

Répondre

0

Vous pourriez envisager une hiérarchie de dossiers comme celui-ci:

Main folder 
|- F folder 
| |- .git 
| |- sources 
| |- build.gradle (with parts specific to F) 
|- P folder 
| |- sources 
| |- build.gradle (with part specific to P) 
|- build.gradle (with common parts) 
|- settings.gradle 

donc vous pouvez toujours décider de lancer gradle soit sur le projet F, le projet P ou les deux alltoegether. Il vous permettra également de vous promouvoir seul projet F sans le P ou d'autres projets secondaires.

Pour plus d'informations à jour, consultez le Multi Project Builds chapter de la documentation Gradle.

+0

Merci pour cela. J'avais vérifié cette section. C'est la structure standard et tout irait bien. Mais, si je ne veux pas que P réside dans le même dossier que F? Je veux être en mesure d'ajouter P2 dans son propre dossier, et P3 dans son propre dossier, etc. P2 et P3 appartiennent à des clients différents et ne devraient pas se voir. La façon normale d'y parvenir serait un dépôt dans lequel je laisserais tomber les artefacts F. Mais parce que je développe F, P et peut-être P2 et P3 en même temps, il serait très long de devoir voyager toujours au-dessus du référentiel. Ou peut-être pas, comme c'est juste quelques pots quelque part. –

+0

Eh bien, je dirais que c'est plus un problème de SCM que de problème mineur. Je ne connais pas assez git, mais, par exemple, Mercurial a le concept de sous-dépôt, ce qui signifie que chacun de vos Px serait dans son "propre" dépôt, inclus dans un plus grand qui contient tout ce qui est dans "Dossier principal ". Un autre exemple est SVN où vous pouvez jouer avec des externes, télécharger, au moment de la sortie, d'autres projets et les inclure dans votre hiérarchie de dossiers. – gizmo