# Intellij "httpRequest" ins Projekt mit einbinden?



## PinkMuffin (17. Sep 2020)

Hallo,
intelliJ stellt ja die Funktion "new httpRequest" zur Verfügung, mit der man ja eine API testen und sich die Response ausgeben lassen kann.
Ist es möglich, diese httpRequest bzw. evtl direkt die response ins Java-Projekt einzubinden, wie es mit "normalen" Klassen möglich ist, oder ist das nur zum Testen der API da?


----------



## mrBrown (17. Sep 2020)

Das ist nur zum Testen da.

Du kannst natürlich den Response in einer Datei speichern und die ins Projekt legen, aber das willst du vermutlich nicht?


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Du kannst natürlich den Response in einer Datei speichern und die ins Projekt legen, aber das willst du vermutlich nicht?


Schade. Wenn ich den Dateiinhalt dann aus einer Java-Klasse heraus direkt als Json verwenden könnte, dann würde es was bringen, aber das ist wahrscheinlich auch wieder Unsinn, weil ich dafür dann wieder genauso einen Parser brauchen würde, wie er im Moment bei meiner Request im Java-File selbst auch schon nicht funktioniert. Drehe mich damit derzeit wohl ein wenig im Kreis.


----------



## Thallius (17. Sep 2020)

Hae? Wieso machst du den HTTP Request denn nicht einfach im Java Code. Dann hast du doch den gleichen Response?


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> Hae? Wieso machst du den HTTP Request denn nicht einfach im Java Code. Dann hast du doch den gleichen Response?


Ich weiß, allerdings habe ich mit meinen Requests bisher immer das Problem, dass ich sie nicht parsen oder überhaupt irgendwie benutzen kann. 
Als Anfänger hatte ich so ein bisschen die Hoffnung, dass man die Response von der httpRequest direkt verwenden kann, da sie ja auch auf der Konsole ausgegeben wird.
Immer wenn ich einen Parser aus einer Bibliothek verwenden will, kommt eine Fehlermeldung, dass das Package nicht existiert (obwohl die Dependencies da sind und mvn install, mvn clean und mvn compile fehlerfrei durchlaufen).


----------



## Thallius (17. Sep 2020)

dann mach es halt erstmal ohne maven und pack die benötigte lib direkt in die jar. Das geht mit IntelliJ sehr einfach in den Projekt-Einstellungen.
Ich würde als Anfänger eh nicht gleich so viele Baustellen auf einmal aufmachen.
Konzentriere dich erstmal auf den Code und dann kannste dich später mit build und deployment tools noch genug rumärgern.

Alternativ kannst auch einfach deinen eigenen JSON parser schreiben. Ist auch ne nette Übung.


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> dann mach es halt erstmal ohne maven und pack die benötigte lib direkt in die jar. Das geht mit IntelliJ sehr einfach in den Projekt-Einstellungen.
> Ich würde als Anfänger eh nicht gleich so viele Baustellen auf einmal aufmachen.


Kann ich das nachträglich dann ohne größere Probleme ändern? 
Das ist nämlich das Problem als Praktikant: Man kann sich nicht so direkt aussuchen, wie man die Sachen macht, mir wurde gesagt, dass ich IntelliJ, Maven und die Atlassian-Doku nehmen soll  😬


----------



## Thallius (17. Sep 2020)

Dann sollte ja auch jemand da sein der dir hilf die maven dependencies richtig einzurichten....


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> Dann sollte ja auch jemand da sein der dir hilf die maven dependencies richtig einzurichten....


Wäre dem so, würde ich ja nicht verzweifelt irgendwelche Foren und Google bemühen. Die Person von der ich die Aufgabe habe, ist im Homeoffice und ein Kollege hat gestern drüber geschaut und einen "Fehler" gefunden, der das Problem dann aber auch nicht gelöst hat.


----------



## mrBrown (17. Sep 2020)

Den Weg ohne Maven (oder vergleichbares) sollte man sich besser gar nicht erst angewöhnen...

Zeig mal deine pom, wenn mvn compile allerdings fehlerfrei durchläuft, ist das üblicherweise korrekt.

Wird das in IntelliJ als Maven-Projekt erkannt?


----------



## Thallius (17. Sep 2020)

mrBrown hat gesagt.:


> Den Weg ohne Maven (oder vergleichbares) sollte man sich besser gar nicht erst angewöhnen...



Ansichtssache. Ich finde man sollte gerade am Anfang alle möglichen Fehlerquellen aussen vor lassen. Du sieht ja hier am besten was dabei rauskommt. Tagelanger Frust und kein weiterkommen.

Man kann viel einfacher erstmal das Projekt mit eingebundenen Libs fertig machen und dann nach und nach alle Libs rausnehmen und einzeln in maven hinzufügen. Dann hat man maximal einen Fehler den man suchen muss


----------



## mrBrown (17. Sep 2020)

Thallius hat gesagt.:


> Ansichtssache. Ich finde man sollte gerade am Anfang alle möglichen Fehlerquellen aussen vor lassen. Du sieht ja hier am besten was dabei rauskommt. Tagelanger Frust und kein weiterkommen.


Am Anfang arbeitet man deshalb ohne Dependencies.

Wenn man Dependencies braucht, ist Maven meiner Erfahrung (mit ein paar hundert Studenten die Porgrammieren lernen) nach die kleinere Fehlerquelle. Allein schon, dass man sich um transitive Dependencies nicht kümmern muss und dass die Konfiguration einfacher Text ist, ist eine einglaubliche Erleichterung – alles ist besser als "Screenshot-Debugging" mit 3 verschiedenen IDEs...


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Zeig mal deine pom, wenn mvn compile allerdings fehlerfrei durchläuft, ist das üblicherweise korrekt.


Da ich es als Maven-Projekt erstellt habe, wird das auf jeden Fall erkannt. Gestern hatte ich kurzzeitig das Problem, dass es mir im target-ordner keine Klassen erstellt hat, weil es gedacht hat, es wäre Kotlin, aber da jetzt der target-ordner funktioniert, dürfte das kein Problem mehr sein.

```
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>JiraWorklogExport</artifactId>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
            <groupId>com.squareup.okhttp3</groupId>
            <artifactId>okhttp</artifactId>
            <version>4.9.0</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.10.3</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>
</project>
```
In der Pom selbst ist nichts rot dargestellt.
Wenn ich mit strg+b den Ursprung der Importe anzeige, geht es auch an die richtige stelle.
In den Module-Settings habe ich einen möglichen Fehler gefunden, allerdings hatte dazu mein Arbeitskollege gesagt, dass es nicht so schlimm wäre:


----------



## mrBrown (17. Sep 2020)

Änder den Scope von junit mal von "compile" zu "test".




PinkMuffin hat gesagt.:


> In den Module-Settings habe ich einen möglichen Fehler gefunden, allerdings hatte dazu mein Arbeitskollege gesagt, dass es nicht so schlimm wäre:


Ja, die sind auch egal.


Und wann und wo kommt jetzt die Fehlermeldung, dass die Packages nicht gefunden werden?


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> Ansichtssache. Ich finde man sollte gerade am Anfang alle möglichen Fehlerquellen aussen vor lassen. Du sieht ja hier am besten was dabei rauskommt. Tagelanger Frust und kein weiterkommen.


Im Prinzip erspart man sich vielleicht Frust, allerdings kann ich mir nicht vorstellen, dass man mir als Praktikant eine wichtige Aufgabe geben würde, die schnell fertig werden muss. Ich denke sie werden mir schon mit Absicht diese Vorgaben gemacht haben, eben damit ich solche Fehlerquellen kennen lerne.


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Änder den Scope von junit mal von "compile" zu "test".


Hab ich gemacht, jetzt kann ich das Projekt nicht mehr starten.

Die Fehlermeldung kam in der Konsole, wenn ich versucht habe, die main laufen zu lassen


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> Hab ich gemacht, jetzt kann ich das Projekt nicht mehr starten.


Ich dachte genau das war schon vorher das Problem? 

Nur der Scope von JUnit muss geändert werden, und alles was mit Junit zu tun hat sollte aus deinem Projekt raus (außer in Unit-Tests, die du aktuell vermutlich nicht hast).




PinkMuffin hat gesagt.:


> Die Fehlermeldung kam in der Konsole, wenn ich versucht habe, die main laufen zu lassen


Was passiert bei 'mvn compile'? (Nachdem Junit aus dem Projekt entfernt wurde).


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Ich dachte genau das war schon vorher das Problem?


Schon, aber da hatte ich die Möglichkeit noch. Die Auswahl "run" ist neben meiner Main verschwunden. Und die Klassen haben keinen Zugriff mehr aufeinander. Aber das hat sich erledigt, das ist durch den Maven-compile wieder gekommen.
Der hat keinen Fehler ausgegeben, nur eine Warning, aber die ist laut Kollege auch nicht relevant. Die Package-Fehler sind genau wie vorher.


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> Aber das hat sich erledigt, das ist durch den Maven-compile wieder gekommen.


Das klingt danach, als ist das Projekt nicht korrekt importiert.



Sind die Junit-Imports (und deren Nutzung) jetzt entfernt?

Und mvn compile läuft auch wirklich korrekt durch, am Ende steht irgendwas mit Success?


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Das klingt danach, als ist das Projekt nicht korrekt importiert.


Ja, sieht auch anders aus als vorher. Wenn ich nicht völlig daneben gegriffen habe, ist das dann entstanden, als ich junit auf test gesetzt habe und bestätigt hab.
(target-Ordner ist weg, "test"- und "main"-Ordner fehlen)

"Build success"
Nur wieder zwei Warnings ganz unten:
[WARNING] The requested profile "development" could not be activated because it does not exist.
[WARNING] The requested profile "win-amd64" could not be activated because it does not exist.


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> Ja, sieht auch anders aus als vorher. Wenn ich nicht völlig daneben gegriffen habe, ist das dann entstanden, als ich junit auf test gesetzt habe und bestätigt hab.
> (target-Ordner ist weg, "test"- und "main"-Ordner fehlen)


Vermutlich solltest du das Projekt noch einmal ganz neu importieren.

.idea-Ordner löschen, die iml-Datei löschen und dann neu öffnen.

Welche IntelliJ-Version nutzt du?


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Vermutlich solltest du das Projekt noch einmal ganz neu importieren.
> 
> .idea-Ordner löschen, die iml-Datei löschen und dann neu öffnen.
> 
> Welche IntelliJ-Version nutzt du?


Hat keinen, für Laien erkennbaren, Unterschied gemacht, die Ordner fehlen immer noch. Ich wollte jetzt ein neues Projekt machen und einfach die Inhalte kopieren (dependencies, importe und klassen), aber da fängt der Fehler noch früher an und ich kann die Komponenten nicht einmal importieren, trotz Dependency (die libraries fehlen allerdings auch in der Struktur, obwohl ich mvn install, clean, compile, etc durchprobiert habe)..

Meine Intellij-Version ist 2020.1.1;
die runtime-version: 11.0.6+8-b765.40 amd64


----------



## Thallius (17. Sep 2020)

Also 

mvn install

wirft einen Fehler?


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> Also
> 
> mvn install
> 
> wirft einen Fehler?


Nein, mvn install:install wirft einen, allerdings sagen Internet und Kollege gleichermaßen, dass diese Fehler nicht so wichtig sind, solange mvn install mit "Build success" endet.


----------



## Thallius (17. Sep 2020)

aber wenn mvn install durchläuft, dann hast du danach doch eine lauffähige .jar Datei.


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> aber wenn mvn install durchläuft, dann hast du danach doch eine lauffähige .jar Datei.



sollte eigentlich, allerdings ist bisher immer die Datei in der External Library aufgeführt worden, da fehlen sie jetzt. In dem Ordner, der da angezeigt wird, sind zwar benutzbare Klassen, aber da ist weder Jackson, noch okhttp dabei. Die müssten mir ja eigentlich auch per Eingabehilfe angezeigt werden (war zumindest immer so, wo man sie dann importieren kann. Das fehlt auch)


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> mvn install:install


Nur `mvn install`, nicht `mvn install:install`!
(Davon abgesehen ist install nahezu nie das, was du willst)



PinkMuffin hat gesagt.:


> allerdings sagen Internet und Kollege gleichermaßen, dass diese Fehler nicht so wichtig sind, solange mvn install mit "Build success" endet.


*Fehler* sind immer relevant, bei einem Fehler endet es auch nicht mit success – *Warnungen* _können_ egal sein, allerdings ist man selbst schuld, wenn man sie ignoriert 




PinkMuffin hat gesagt.:


>


Zeig noch mal die *aktuelle* pom.xml.


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> *Fehler* sind immer relevant, bei einem Fehler endet es auch nicht mit success – *Warnungen* _können_ egal sein, allerdings ist man selbst schuld, wenn man sie ignoriert


Ja, das stimmt, allerdings ignoriere ich eine Warnung, die ich nicht verstehe lieber, bevor ich sie noch zu einem ausgewachsenen Fehler mache  😅 
bei install:install sind es tatsächlich Fehler, keine Warnungen. Der endet aber auch nicht mit "success"

Die Pom sieht so aus: (Das Projekt heißt anders, weil das andere für mich so unnutzbar war (fehlende Ordnerstruktur, etc), dass ich ein neues gemacht habe und die Werte aus dem alten genommen habe)

```
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>JiraTry</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>com.squareup.okhttp3</groupId>
            <artifactId>okhttp</artifactId>
            <version>4.9.0</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.10.3</version>
        </dependency>
    </dependencies>

</project>
```


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> bei install:install sind es tatsächlich Fehler, keine Warnungen. Der endet aber auch nicht mit "success"


Liegt bei install:install daran, dass es nicht das macht, was du willst – es kopiert nur die fertige jar (die bei install:install nicht gebaut wird) in's lokale Repo.



PinkMuffin hat gesagt.:


> Die Pom sieht so aus: (Das Projekt heißt anders, weil das andere für mich so unnutzbar war (fehlende Ordnerstruktur, etc), dass ich ein neues gemacht habe und die Werte aus dem alten genommen habe)


Die pom ist völlig korrekt, irgendwas ist beim Import in IntelliJ falsch gelaufen.

Projekt in IntellIj schließen
Über den Explorer/Konsole den .idea-Ordner und die iml-Datei löschen
In IntelliJ auf "Open...", dann dort die pom.xml auswählen
In dem Dialog dann "Open as Project" wählen


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Liegt bei install:install daran, dass es nicht das macht, was du willst – es kopiert nur die fertige jar (die bei install:install nicht gebaut wird) in's lokale Repo.


Gut zu wissen, hab nur gelesen, dass man eigentlich immer über lifecycle gehen soll und nicht über die Plugins.



mrBrown hat gesagt.:


> Projekt in IntellIj schließen
> Über den Explorer/Konsole den .idea-Ordner und die iml-Datei löschen
> In IntelliJ auf "Open...", dann dort die pom.xml auswählen
> In dem Dialog dann "Open as Project" wählen


Exakt so durchgeführt, die besagten Files (Okhttp & Jackson) sind jetzt auch in der External library angezeigt und können mit der Eingabehilfe importiert werden, allerdings ist der Fehler von vorhin immer noch da, sobald ich auf "run" klicke:


----------



## Thallius (17. Sep 2020)

PinkMuffin hat gesagt.:


> Anhang anzeigen 14053
> sollte eigentlich, allerdings ist bisher immer die Datei in der External Library aufgeführt worden, da fehlen sie jetzt. In dem Ordner, der da angezeigt wird, sind zwar benutzbare Klassen, aber da ist weder Jackson, noch okhttp dabei. Die müssten mir ja eigentlich auch per Eingabehilfe angezeigt werden (war zumindest immer so, wo man sie dann importieren kann. Das fehlt auch)



Was ist denn in Target drin?


----------



## PinkMuffin (17. Sep 2020)

Thallius hat gesagt.:


> Was ist denn in Target drin?



Die Klasse und anscheinend was, was der Compiler gebastelt hat.


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> Gut zu wissen, hab nur gelesen, dass man eigentlich immer über lifecycle gehen soll und nicht über die Plugins.


Ja, und mit install:install ignorierst du die Phasen halt 



PinkMuffin hat gesagt.:


> Exakt so durchgeführt, die besagten Files (Okhttp & Jackson) sind jetzt auch in der External library angezeigt und können mit der Eingabehilfe importiert werden, allerdings ist der Fehler von vorhin immer noch da, sobald ich auf "run" klicke:


Update uU mal deine IDE, uU liegt da ein Fehler


----------



## Thallius (17. Sep 2020)

Wenn in deinem Target Ordner keine .jar ist, dann kann der mvn install auch nicht funktioniert haben. Das hat mit der IDE nix zu tun.


----------



## PinkMuffin (17. Sep 2020)

mrBrown hat gesagt.:


> Update uU mal deine IDE, uU liegt da ein Fehler


Ohje, ich bekomme da nur ein "connection refused", an der IDE kann ich wohl nichts umstellen, damit werde ich warten müssen, bis die Leute mit Rechten mal wieder im Büro sind. Diese Homeoffice-Situation ist echt unpraktisch, heute war nur ein Entwickler da, und der hatte logischerweise Wichtigeres zu tun  😬 ..


----------



## Thallius (17. Sep 2020)

Kannst du nicht erstmal ein hello world maven project aus einem tutorial aus dem netz erstellen und zusehen das das läuft? Dann kannst du nach und nach daran Änderungen vornehmen wie erstmal dem ganzen deinen Projectnamen geben, es in die IDE integrieren etc. und dann fängst du an und fügst die verschiedenen source dazu die du schon hast.

Und fang erstmal ohne IDE an. Mach alles mit nem editor auf Konsolen ebene. Dann verstehst du auch was da passiert.


----------



## mrBrown (17. Sep 2020)

Thallius hat gesagt.:


> Wenn in deinem Target Ordner keine .jar ist, dann kann der mvn install auch nicht funktioniert haben. Das hat mit der IDE nix zu tun.


Bei mvn install wird die jar gebaut und in's lokale Repo gelegt.

Ich bin mir nicht sicher ob du damit meinst, dass ohne install keine jar im Target-Ordner liegt, oder ohne jar im Target-Ordner install nicht funktioniert...

mvn install ist zumindest um nur die jar zu bauen das falsche.


----------



## Thallius (17. Sep 2020)

mrBrown hat gesagt.:


> Bei mvn install wird die jar gebaut und in's lokale Repo gelegt.
> 
> Ich bin mir nicht sicher ob du damit meinst, dass ohne install keine jar im Target-Ordner liegt, oder ohne jar im Target-Ordner install nicht funktioniert...
> 
> mvn install ist zumindest um nur die jar zu bauen das falsche.



Also bei mir wird bei install die jar im target Verzeichnis erzeugt.... Was du jetzt unter lokalem repo verstehst ka, für mich ist das lokale repo einfach der Ordner indem das project liegt und da wird nix erzeugt.


----------



## mrBrown (17. Sep 2020)

Thallius hat gesagt.:


> Also bei mir wird bei install die jar im target Verzeichnis erzeugt.... Was du jetzt unter lokalem repo verstehst ka, für mich ist das lokale repo einfach der Ordner indem das project liegt und da wird nix erzeugt.


Ich glaube du solltest dich noch mal mit Maven beschäftigen, wenn du weder weißt was install macht, noch was das lokale Repo ist 🤨

In der `package`-Phase wird das Artefakt (zB eine Jar mit jar:jar, je nach Format) gebaut und liegt danach im Target-Ordner.

In der `install`-Phase (genauer im `install:install`-Goal) wird das vorher erzeuge Artefakt in das lokale Repository gelegt, welches überlicherweise in ~/.m2 liegt. Im lokalen Repo liegen alle Artefakte, die du mit Maven nutzte, es ist quasi eine "lokale Kopie" von Maven Central plus deine lokal installierten Artefakte.


----------



## PinkMuffin (17. Sep 2020)

Ist es in dem Fall eigentlich normal, dass ich keine mvn.exe-Datei finden kann? Mit Maven müsste ja alles in Ordnung sein, wenn ich es in der IDE ja benutzen kann, oder?
Weil ich wollte das mit der mvn-Kommandozeile versuchen, von der Eingabeaufforderung aus geht es jedoch nicht und eine mvn.exe lässt sich auch nicht finden. (Nicht dass es am Ende daran lag/liegt)


----------



## Thallius (17. Sep 2020)

mrBrown hat gesagt.:


> Ich glaube du solltest dich noch mal mit Maven beschäftigen, wenn du weder weißt was install macht, noch was das lokale Repo ist 🤨
> 
> In der `package`-Phase wird das Artefakt (zB eine Jar mit jar:jar, je nach Format) gebaut und liegt danach im Target-Ordner.
> 
> In der `install`-Phase (genauer im `install:install`-Goal) wird das vorher erzeuge Artefakt in das lokale Repository gelegt, welches überlicherweise in ~/.m2 liegt. Im lokalen Repo liegen alle Artefakte, die du mit Maven nutzte, es ist quasi eine "lokale Kopie" von Maven Central plus deine lokal installierten Artefakte.



Tja, dann hat maven wohl ein hidden feature. Ich brauche jedenfalls nur man install aufrufen und bekomme meine fertige .jar im target Ordner.


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> Ist es in dem Fall eigentlich normal, dass ich keine mvn.exe-Datei finden kann? Mit Maven müsste ja alles in Ordnung sein, wenn ich es in der IDE ja benutzen kann, oder?
> Weil ich wollte das mit der mvn-Kommandozeile versuchen, von der Eingabeaufforderung aus geht es jedoch nicht und eine mvn.exe lässt sich auch nicht finden. (Nicht dass es am Ende daran lag/liegt)


Was hast du denn die ganze Zeit gemacht, wenn du sagst `mvn install` läuft durch?


----------



## mrBrown (17. Sep 2020)

Thallius hat gesagt.:


> Tja, dann hat maven wohl ein hidden feature. Ich brauche jedenfalls nur man install aufrufen und bekomme meine fertige .jar im target Ordner.



Nichts daran ist hidden, dass sollte man nach eine Grundeinführung in Maven wissen... Es werden immer auch die vorherigen Phasen ausgeführt, und bei install ist das eben package, install selber kopiert nur die jar herum.


----------



## Thallius (17. Sep 2020)

mrBrown hat gesagt.:


> Nichts daran ist hidden, dass sollte man nach eine Grundeinführung in Maven wissen... Es werden immer auch die vorherigen Phasen ausgeführt, und bei install ist das eben package, install selber kopiert nur die jar herum.



und was ist dann an install verkehrt ausser das es einen zusätzlichen Schritt ausführt den man in dem Moment nicht direkt braucht? Sorry aber Deine Erbsenzählerei ist echt nervig


----------



## mrBrown (17. Sep 2020)

Thallius hat gesagt.:


> und was ist dann an install verkehrt ausser das es einen zusätzlichen Schritt ausführt den man in dem Moment nicht direkt braucht? Sorry aber Deine Erbsenzählerei ist echt nervig


Ne, keine Ahnung haben und anderen dann etwas falsches erklären ist nervig.

Wenn jemand mit Maven beginnt, ist es einfach nur völlig dumm, dem etwas Falsches zu sagen, was halt zufällig auch das richtige macht, anstatt einfach direkt das richtige.

Mag sein, dass es dich zufriedenstellt, wenn es halt irgendwie funktioniert aber du keine Ahnung hast warum und was du da eigentlich machst – mir reicht das nicht.


----------



## Thallius (17. Sep 2020)

mrBrown hat gesagt.:


> Mag sein, dass es dich zufriedenstellt, wenn es halt irgendwie funktioniert aber du keine Ahnung hast warum und was du da eigentlich machst – mir reicht das nicht.



Haha sagt jemand der drauf schwört möglichst viele Tools und Frameworks zu benutzen statt den Code selber zu schreiben. DA weißt du nämlich nie was die eigentlich machen.... 
Ich frage mich oft wie viele Backdoors es in den aktuellen Softwares gibt weil die hunderte open source frameworks einsetzen die von tausenden von Entwicklern programmiert werden und die keiner wirklich überprüft.


----------



## mrBrown (17. Sep 2020)

Spoiler: OT






Thallius hat gesagt.:


> Haha sagt jemand der drauf schwört möglichst viele Tools und Frameworks zu benutzen statt den Code selber zu schreiben.


Ne, eigentlich schwör ich da nicht drauf. Tools und Framework sind btw völlig unterschiedliche Dinge, die grad bei sowas absolut nicht zu vergleichen sind...


Thallius hat gesagt.:


> DA weißt du nämlich nie was die eigentlich machen....


Das ist schon amüsant, nachdem du grad noch gesagt hast, keine Ahnung zu haben was ein Tool macht, welches du nutzt...




Thallius hat gesagt.:


> Ich frage mich oft wie viele Backdoors es in den aktuellen Softwares gibt weil die hunderte open source frameworks einsetzen die von tausenden von Entwicklern programmiert werden und die keiner wirklich überprüft.


Die Open-Source-Frameworks werden garantiert von mehr Entwicklern überprüft und getestet, als die Programme, die du allein entwickelst.

Qualität erreicht man nicht einfach so, indem man alleine alles entwickelt. In den seltensten Fällen hat man Zeit und Können, und wenn man das hat, um eine gleichwertige Lösung selbst zu entwickeln, steckt in der OS-Lösung nahezu immer trotzdem ein Vielfaches an Erfahrung, Wissen und vor allem Testing, welches man in der Form nie bieten kann.
Natürlich gibt es einen Punkt, an dem selbst entwickeln günstiger ist, als fertige Lösungen zu entwickeln — der ist allerdings für jedes Projekt und jede Abhängigkeit anders. Spring Framework einbinden, weil man deren StringUtils#isEmpty braucht, ist ziemlich dumm. Swing nicht nutzen, sondern ein eigenes GUI-Framework schreiben, um eine Stoppuhr anzuzeigen, ist allerdings genauso dumm. Zumindest für meine Projekte könnte ich für jede Abhängigkeit Kosten, Nutzen und Risiko abwägen, und in den meisten Fällen ist das auch mit anderen durchgesprochen.
Waren die Dinge immer Bugfrei? Nein, keineswegs, es sind durchaus auch einige Bug-Reports und Fixes bei rumgekommen. Aber hätte ich es selbst besser lösen können? Nein, in nur wenigen Fällen würde ich mir eine bessere, funktional gleichwertige Lösung zutrauen oder hätte überhaupt Zeit dazu — in den anderen Fällen wurde dass dann in entsprechende OS-Projekt eingebracht.

Es ist nie einfach ein „nimm das Framework“, das hat immer eine Grundlage — und die sollte man auch haben, wenn man sich gegen die Nutzung von Frameworks oder Libraries ausspricht, ansonsten ist das nicht mehr als eine völlig unbegründete Meinung, und die sind nahezu immer Unsinn.


----------



## mrBrown (17. Sep 2020)

PinkMuffin hat gesagt.:


> Exakt so durchgeführt, die besagten Files (Okhttp & Jackson) sind jetzt auch in der External library angezeigt und können mit der Eingabehilfe importiert werden, allerdings ist der Fehler von vorhin immer noch da, sobald ich auf "run" klicke:


Warum ich nach der Version gefragt hatte: genau den gleichen Fehler hatte ich auch mal, war allerdings eine EAP, irgendwann (ich glaube mit dem Update auf die normale Version) war’s dann plötzlich weg.
Das ist in jedem Fall kein Maven-Fehler.


----------



## PinkMuffin (18. Sep 2020)

mrBrown hat gesagt.:


> Was hast du denn die ganze Zeit gemacht, wenn du sagst `mvn install` läuft durch?


Nicht die Kommandozeile genutzt. Deswegen habe ich nachgefragt. 
Ich habe in IntelliJ den maven-reiter ausgewählt. 

Da das der Kollege genauso gemacht hat, gehe ich davon aus, dass es das gleiche ist, es irritiert mich nur irgendwie, dass ich nicht an die Kommandozeile komme (außer "execute maven goal" ist die Commandline) 😅


----------



## PinkMuffin (18. Sep 2020)

mrBrown hat gesagt.:


> Das ist in jedem Fall kein Maven-Fehler.


Okay danke für die Info, dann weiß ich zumindest schon einmal, wo ich nicht suchen muss. Da ich eben nur grundlegende Java- (und mittlerweile auch mikroskopische Maven-Kenntnisse) habe, bin ich leider relativ überfordert, sobald etwas kein Syntax- oder Logikfehler ist 😬


----------

