# Gradle



## nocheinPoet (22. Sep 2019)

Moin,

habe lange mit JAVA entwickelt, dynamische Webseiten, also Applikationen, so mit Struts, EJB, JSP, ANT, SVN, Eclipse, Tomcat, JBoss ... eben in diesem Umfeld um ein paar Abkürzungen zu nennen. Nun will ich mal wieder was in die Richtung machen, meine Skills auffrischen und hab mir die neuste Version von Eclipse gezogen, ein paar Plugins, will mir neue Sprachen im Umfeld JAVA ansehen und auch Build-_Werkzeuge_ und was fürs Deployment.

Früher war ANT angesagt, MAVEN war noch jung, nun fand ich Gradle und hab mir dazu was angesehen, hoffe der Link ist erlaubt:









						Die Anleitung zum Gradle für den Anfänger | codestory.de
					






					o7planning.org
				




Was mich nun echt verwundert, ich muss für die Bibliotheken wie _*common-lang3*_ da wo nach Name und Version suchen und das von Hand in die _*build.gradle*_ pinseln?

Das wird nicht automatisch gemacht? 

Ich finde das wo recht aufwendig, gibt es da Lösungen, die aus dem Quellcode selber die _*build.gradle*_ generieren oder anpassen?


Lieben Gruß

Manuel


----------



## mrBrown (22. Sep 2019)

Der übliche Weg ist schon, sich die Lib zu suchen, die man nutzen will, und die dann eben einzutragen. Was findest du denn daran aufwendig?


IDEs können das zT unterstützen, mindstens mit Autovervollständigung, manchmal auch indem sie zu einer Klasse die passende Dependency vorschlagen.

Gegen automatisch spricht aber mMn einiges (Klasse<->Dependency ist nicht eindeutig, Suchraum ist deutlich zu groß, transitive Dependencies müssen irgendwie beachtet werden, ...)


----------



## nocheinPoet (22. Sep 2019)

Moin,

ich kenne es von Eclipse, da wird der Import dann angeboten, so was in der Richtung sollte schon gegeben sein, könnte ja eine Auswahl angeboten werden. Gibt ja Projekte ja ist die Liste für Import echt lang, sehr lang, und nun für jeden da auf eine Seite im Netz zu gehen und sich das zu suchen, auszuwählen und dann per Copy & Paste in die _*build.gradle*_ zu drücken ...

Ich denke eben, dafür gibt es ja Rechner, da so ein Dialog, soll ... in die _*build.gradle*_ eingefügt werden, mit Auswahl der möglichen Versionen ist sicher nicht schwer zu realisieren. Nun wird es wohl heißen, ich bin zu bequem ...


----------



## mrBrown (22. Sep 2019)

Zumindest IntelliJ bietet in der build.gradle/pom.xml Autovervollständigung, wenn man tippt. Ich würde davon ausgehen, dass Eclipse das genauso kann, mindestens die Version sollte sich damit autovervollständigen lassen.




nocheinPoet hat gesagt.:


> Gibt ja Projekte ja ist die Liste für Import echt lang, sehr lang, und nun für jeden da auf eine Seite im Netz zu gehen und sich das zu suchen, auszuwählen und dann per Copy & Paste in die _*build.gradle*_ zu drücken ...



Naja, aus eigener Erfahrung ist das kein Aufwand, den man irgendwie merken würde...
Zumindest ich hab selten eine Liste von X Libs im Kopf, die ich gerne nutzen würde (und selbst wenn es so wäre, fallen die paar Sekunden pro Lib kaum nicht ins Gewicht). In den meisten Fällen hat man ja sowieso mal die Doku, das Projekt, irgendein Wiki oä dazu offen, wo die Koordinaten üblicherweise recht prominent stehen.




nocheinPoet hat gesagt.:


> Ich denke eben, dafür gibt es ja Rechner, da so ein Dialog, soll ... in die _*build.gradle*_ eingefügt werden, mit Auswahl der möglichen Versionen ist sicher nicht schwer zu realisieren. Nun wird es wohl heißen, ich bin zu bequem ...


zT ist das schon recht schwer, einfach mal als Beispiel mit commons-lang3:

commons-lang3 ist in X Projekten eingebunden sein, zT direkt in der Jar (wenn's ne "Fat-Jar" ist) und zT transitiv - und X dürfte dabei eher vier- als dreistellig sein. Ein Vorschlag nur aufgrund einer genutzten Klasse müsste dann alle Projekte vorschlagen, du müsstest also immer noch selbes das passende raussuchen.
Um aber überhaupt mal auf die Liste der X Projekte zu kommen, müsste jede verfügbare Lib gescannt werden, ob sie das jeweilige enthält ('nen zentralen Index gibts da bisher afaik noch nicht), und allein in Maven Central sind mehr als Vier Millionen Artefakte verfügbar.


----------



## kneitzel (22. Sep 2019)

Also bei den Gradle dependencies geht es ja um die externen Abhängigkeiten. Das ist also das, was man sonst eigenständig herunterladen und installieren musste.

Da ist der Eintrag selbst schon extrem komfortabel.

Bezüglich des automatisch Vorschlägen von Imports:
A) Externe Abhängigkeiten einfach so einbinden finde ich problematisch. Das sollte immer ein bewusster Schritt sein (mit Prüfung der Lizenz, Notwendigkeit, .. )
B) Über eine Klasse oder Namespace etwas vorschlagen ist schwer, denn oft gibt es sehr viele Möglichkeiten. Und die Datenbank wird dann auch extrem gross (Jede Lib kann da ja eingebunden werden ... Da hat sich also schon viel Mist angesammelt).

Und wenn man Projekte baut, dann ist dies auch unproblematisch:
- man kennt seine Abhängigkeiten ja. Ich nutze eigentlich immer die gleichen paar Libraries.
- für neue Projekte gibt es Templates und Generatoren. Da klickt man dann halt an, was man so braucht. Spring ist da ein gutes Beispiel würde ich sagen.


----------

