Quel est le but de Gradle?
je pourrais avoir besoin d'un peu d'aide pour comprendre les concepts derrière Gradle(plugin V 0.7) dans le contexte D'Android Studio 0.4.0. Je n'ai jamais utilisé Gradle avant et ça ne me cause que des problèmes. Je ne vois pas son but/bénéfice parce que je n'en sais pas assez à ce sujet.
Certaines des questions que j'ai
quelles sont ces dépendances? Je fais une application simple avec un tiroir de navigation, ciblé à L'API 11+ où il devrait être nativement soutenu. Quelles sont les dépendances pourrais-je utiliser?
qu'est Ce qu'un Gradle wrapper? Quels changements, le cas échéant, faut-il faire la demande?
pourquoi Gradle doit-il être constamment en ligne? Je n'ai pas accès internet sur mon portable personnel quand je suis au travail. Il est devenu au point que je ne peux pas lancer ou tester mon application parce que Gradle ne peut pas résoudre certaines ressources, sans accès internet.
Pourquoi est-il important que Grad utilise Groovy? J'ai cherché autour de l'internet et qui tend à être quelque chose que les gens aiment Grad mais ils n'expliquent généralement pas pourquoi Groovy est important ou ce qu'il fait pour une application Android.
parfois, c'est difficile comme programmeur intermédiaire car l'information a tendance à être trop simple ou trop complexe. En dehors de mes questions spécifiques, toute information supplémentaire que vous pourriez fournir serait utile. Je ne cherche pas à débattre les avantages et les inconvénients de Gradle vs autres outils qui peuvent faire la même chose, je voudrais juste en savoir plus sur Gradle et son utilisation afin que je puisse prendre des décisions éclairées.
Merci
4 réponses
Certaines de vos questions sont générales qu'ils parlent de pourquoi construire des outils sont une bonne chose en général. D'autres pour obtenir de Gradle spécifiquement. Je vais essayer d'aborder les deux catégories aussi succinctement que possible tout en essayant d'éviter la terminologie pince-sans-rire des autres.
construisez des outils comme Maven, Gradle, SBT, Leiningen, etc. aide à automatiser les tâches que nous aurions autrement à effectuer manuellement ou " automatiser manuellement."J'utilise ce dernier pour décrire ce que j'avais l'habitude de faire avec Ant -- écriture de tâches personnalisées pour compiler, exécuter, générer Javadoc, etc. donc, les tâches peuvent être automatisées pour l'avenir. En se conformant aux conventions originellement définies par Maven et adoptées par les autres par la suite (comme mettre votre source dans src / main / java), cela devient possible. Si je suis les conventions, l'outil de compilation peut compiler, exécuter, générer Javadoc, tester, et tout le reste avec un minimum de travail supplémentaire.
Maintenant à vos questions (en l'ordre):
- une autre fonction essentielle des outils de construction est de réduire "l'enfer des pots" en gérant les dépendances de manière cohérente entre les constructions. Je spécifie juste quelle version D'Apache Commons ou Google Guava ou Spring ou Jackson je veux (ou même la gamme de versions) et l'outil de compilation va les télécharger et les mettre quelque part pour qu'ils puissent être dans classpath et dans la compilation si applicable (comme un fichier de guerre). Je peux aussi définir des portées--comme je veux que cette dépendance soit disponible à compilez le temps mais l'autre seulement à l'exécution. Dois-je fournir explicitement, ou seront-ils disponibles? Des trucs comme ça.
- ceci est spécifique à Gradle. Tel que décrit ici, le gradle wrapper aide les équipes à exécuter Gradle sans avoir à installer manuellement Gradle tout en maintenant la cohérence. Tout le monde utilise la même version. Une fois que vous l'avez configuré, vous n'avez plus à vous en soucier, et toutes les tâches de Grad que vous voulez utiliser sont disponibles via l'emballage, donc vous avez besoin soucient même pas qu'il est là. Vous pouvez choisir d'installer Gradle directement et de l'exécuter directement, mais je vois rarement l'intérêt.
- C'est général. J'ai mentionné la gestion de la dépendance plus tôt. Afin de récupérer ces dépendances, l'outil de compilation doit se connecter là où elles sont disponibles à partir de Maven Central ou d'un tas de dépôts tiers. Une autre innovation Maven adoptée par les autres est gestion du dépôt, ainsi les artéfacts compilés sont publiés dans un dépôt selon la convention pour que d'autres projets puissent les utiliser. Habituellement, vous ne vous inquiétez pas à ce sujet. Vous dites juste à l'outil que vous avez besoin d'une certaine dépendance, et il sait comment l'attraper parce que tout le monde suit les conventions. Dans les situations où vous êtes sans accès à internet (quelque chose que je suis assez familier avec), vos options sont de simplement saisir toutes les dépendances lorsque vous êtes en ligne et ensuite optionnellement pour mettre en place un dépôt Maven local comme Nexus ou Artifactory pour publier ces artéfacts. Ensuite, vous dites votre outil de construction pour y regarder aussi bien que Maven Central,etc.
- Maven est configuré avec XML, et cela semblait vraiment cool à l'époque. Mais il y a deux conséquences. L'une est que la configuration devient très verbeuse. Une autre est qu'il devient difficile de faire la coutume de choses. Vous devez tout faire de façon déclarative en XML, ce que beaucoup trouvent pénible. Vous configurez les plugins en XML, ou vous écrivez le vôtre et l'enveloppez D'une manière que Maven peut comprendre et peut être configuré en XML. Il est beaucoup plus facile et plus puissant pour faire des trucs personnalisés de construction en code. Gradle a choisi Groovy pour cela parce que Groovy rend pour Nice DSL et est vraiment facile à apprendre pour les développeurs Java venant de Maven. SBT a choisi Scala et Leiningen a choisi Clojure parce que ces outils de construction ciblent ces langages/plateformes, de sorte qu'un développeur Scala, par exemple, n'a pas à apprendre quoi que ce soit de nouveau pour utiliser SBT en dehors de la DSL. Mais le point le plus important est que se fier au code plutôt qu'au XML avantage.
J'espère que ça aidera.
quelles sont ces dépendances?
Il y a tellement de bibliothèques cool que vous pourriez décider d'utiliser. Et beaucoup de ces bibliothèques soutiennent maintenant l'intégration avec gradle. Donc plus besoin d'importer le projet et de l'héberger vous-même. Tout est hébergé sur mavencentral. Vous avez encore besoin de la bibliothèque de soutien par exemple, même si vous décidez de cibler L'API 11+.
qu'est Ce qu'un Gradle wrapper?
un papier d'emballage gradle est un outil génial, si vous travaillez dans une équipe, ou en particulier sur un projet open source. Vous n'avez pas besoin d'avoir gradle installé. Le paquet gradle va télécharger et mettre en cache toutes ses dépendances lors de la première exécution. Si tous les développeurs de votre équipe peut construire le projet très rapidement.
pourquoi Gradle doit-il être constamment en ligne?
Parce que les dépendances doivent être synchronisés. Vous avez de la chance, si vous utilisez Android Studio. La dernière la version supporte un"mode Grad offline".
Studio prend maintenant en charge le mode Gradle Offline. Ceci est utile si vous trouvez vous-même sans connexion réseau, et vos dépendances utilisent la syntaxe plus pour récupérer la dernière version disponible. Dans ce cas, Gradle se connecte à l'artefact une fois par jour (par défaut) dépôt pour voir s'il y a une version plus récente. Si le réseau échec de la connexion, la construction échoue. Si vous n'avez pas de réseau connexion, c'est problématique. Vous pouvez maintenant ouvrir le Compilateur > Grad les options et activer le mode hors ligne, qui indiquera à Grad le ignorer la mise à jour à la date de vérification:
Pourquoi est-il important que Gradle utilise Groovy?
vous écrivez des plugins gradle dans Groovy. Et toutes vos tâches de Grad dans build.gradle.
Attention: je ne suis pas un expert en gradle. En fait relativement nouveau de l'utilisateur.
je comprends ce que tout le monde dit quant à la raison pour laquelle la partie en ligne de Gradle est nécessaire, mais pour ceux d'entre nous derrière les pare-feux au travail, ou quand nous pourrions travailler hors ligne, il nous met vraiment un fardeau de devoir aller en ligne au moins une fois pour être en mesure de compiler en mode hors ligne.
Je ne comprends tout simplement pas pourquoi cette exigence est placée sur le projet. Que faire si je commence un nouveau projet dans Android Studio que je veux tester un concept? Je ne peux pas le faire à moins que je ne sois en ligne au moins une fois. Que faire si je n'ai pas accès à internet, à ce moment, et de vouloir faire cela? Alors, quoi?
semble être une exigence inutile qui impose au développeur des problèmes inutiles qui pourraient être évités. Encore une fois, je comprends la raison derrière cela, mais tout de même, de forcer une exigence d'au moins compiler une fois en ligne afin d'utiliser hors ligne semble un peu ridicule.
je veux utiliser Gradle, mais à ce stade, c'est quelque chose que nous ne pouvons même pas utiliser à le travail en raison de la ligne à l'exigence. Je vais devoir travailler avec notre département de sécurité pour déterminer quels trous à percer dans notre pare-feu afin de permettre cela à travers ainsi que la mise en place de notre proxy correctement pour l'autoriser.
donc, à ce moment, je ne peux pas recommander Gradle pour utilisation à mon lieu de travail qui signifie que nous allons également continuer à utiliser Eclipse pour le développement Android par opposition à Android Studio. C'est une exigence limitative qui ne semble pas nécessaire.
supposons que la compréhension des points suivants serve de base agrégeable:
que sont les classes, les interfaces, les API, les paquets, les modules et les bibliothèques?
qu'est-ce que les dépendances de module et ce qui signifie "gestion de dépendances".
une complexité d'applications modernes. Même si vous faites une simple application" Hello, world " (serait-il une application de bureau ou web-application), il devrait inclure une douzaine (si non une centaine) de différentes bibliothèques. Toutes ces bibliothèques fournissent une infrastructure à votre application, mais beaucoup d'entre elles ne sont pas directement liées à sa logique.
si votre application n'est pas" Hello, world", alors cacher sa complexité (par une modularisation appropriée) et automatiser son assemblage et ses tests (par l'utilisation d'outils de construction appropriés) devient crucial pour le succès.
avec cette compréhension à l'esprit (et en tenant compte des considérations précieuses, énumérées par cher collègues ci-dessus) il est logique de commencer à parler de gradle, ant, ivy et maven.