Interne Dependencies in Maven

[DaBe1812]

Hi,

wir benutzen im Projekt aktuell Eclipse und Ant. Ich wollte schon immer mal Maven ins Projekt bringen, ist aber immer aus irgendwelchen Gründen verschoben worden.

Jetzt ist es aber so weit, dass wir auf IntelliJ und Maven in nächster Zeit umstellen sollen.

Also habe ich mich jetzt dran gesetzt und versuche alle Projekte zu migrieren.

Mein erstes Problem war schon mal das unterschiedliche Konzept von Workspace (Eclipse) und Projekt (IntelliJ). Ich denke aber dass habe ich gelöst mit einem Projekt mit einem Root-Modul und darunter Module für meine einzelnen Java-Tools.

Zu Maven:
Also wir haben viele kleine und größere Java-Programme, die unsere Datenbank hübscher machen soll, also Import-Jobs, nächtliches "sortieren" von Daten, oder Abgleiche mit anderen Datenbanken.
Dazu habe ich mal dann einzelne Funktionen ausgelagert und in die ganzen Tools als Modul eingebunden.
Ein einfaches Beispiel ist das Mailing. Dafür hatte ich ein eigenes Projekt gebaut, in dem ich einzelne Sachen für das Mailing schon vorbelegt habe und man dann von außen nur die Adressaten, den Text und den Betreff und die angehängte Dateien hinzugefügt hat. Damit musste ich bei Änderungen im Mailing in der Firma nur dieses Projekt anpassen und dann alle anderen Projekte neu mit Ant builden und dann war alles korrekt.

Mit IntelliJ und Mavan bekomme ich das jetzt irgendwie nicht hin. Maven sucht die Abhängigkeit nicht bei mir lokal, sondern im Maven Central.

Ich bin gerne bereit alles mögliche um zu stellen, wenn mein alter Ansatz einfach alt ist, aber ich hätte es gerne verstanden, wie ich in Zukunft aus IntelliJ eine funktionierende jar-Datei bekomme, die das Mailing (und weitere Module) aus einem gemeinsamen Pool verwendet.

Leider finde ich beim Suchen nach Maven-Hilfe immer nur so halbfertige Tutorials. IRgendwie fehlt mir der Schritt zur Ausführung außerhalb meiner Entwicklungsumgebung.

Danke für eure Hilfe.

 

[Oneixee5]

IRgendwie fehlt mir der Schritt zur Ausführung außerhalb meiner Entwicklungsumgebung.

Wenn maven korrekt installiert ist und auch die Umgebungsvariablen stimmen, also JAVA_HOME und PATH, dann wechselst du in den Ordner mit deiner pom.xml und tippst z.B.: mvn clean install
mvn ist der Starter für Maven und clean bzw install sind phasen.
Genauer Angaben zu phase, goals und Parametern findest du in der Doku.

 

[kama]

Hallo,

Maven ist ein Build Tool... was ich nicht ganz verstehe

darunter Module für meine einzelnen Java-Tools.

Was ist damit gemeint?
Kannst Du bitte mehr details hier posten.. ?

Mit IntelliJ und Mavan bekomme ich das jetzt irgendwie nicht hin. Maven sucht die Abhängigkeit nicht bei mir lokal, sondern im Maven Central.

Was ist denn Ziel?
Was möchtest Du genau erreichen?

Gruß
Karl Heinz

 

[KonradN]

Ich habe verstanden, dass du Projekte hast, die dann als Abhängigkeit in anderen Projekten benutzt werden. Da gibt es mehrere Lösungen:

- Ohne irgendwas: die Abhängigkeit muss auf dem System zuerst gebaut und installiert werden. Das installiert das Ergenbis im local Repository und damit steht es zur Verfügung.

- In der Anfangszeit kann man die Abhängigkeiten auch als jar hinterlegen. Ich habe dazu bei einem Projekt in libs die jar Dateien und ein Script, dass mvnw aufruft um diese in einem lokalen Repository zu installieren. In src/repository ist dann ein Repository, das in der Pom auch eingebunden wird. Alternativ kannst du die jar auch manuell mit mvn installieren ohne das Projekt zu bauen.

- Du kannst auch ein eigenes Repository aufsetzen. Da gibt es kleine Tools, die das machen. Das hatten wir dann auch schon in einem git Repository um es in einer Entwicklungsumgebung ohne Internet zu nutzen. (Reposilite haben wir verwendet)

Prinzipiell kann man auch jar Dateien direkt einbinden, aber davon wird zu Recht abgeraten. Aber auch das würde man im Netz finden.

 

[DaBe1812]

Okay, als kleines Beispiel:
ich habe folgende Projektstruktur:

"subclass" soll dabei ein Modul sein, welches Funktionen (hier nur die Klasse StringGetter) zur Verfügung stellt, die in vielen Modulen immer wieder benötigt werden, und wenn das Modul verbessert wird, dann sollen auch alle anderen Module direkt davon profitieren.
Die pom dazu:

<?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>
    <parent>
        <groupId>org.daniel</groupId>
        <artifactId>root</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <artifactId>subclass</artifactId>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

Der Code in der Klasse entsprechend auch minimal:

package org.daniel;

public class StringGetter {
    
    public String getSubstring() {
        return "Hello World";
    }
}

Das Modul userClass soll das jetzt verwenden. Die pom dazu:

<?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>
    <parent>
        <groupId>org.daniel</groupId>
        <artifactId>root</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <artifactId>userClass</artifactId>

    <dependencies>
        <dependency>
            <groupId>org.daniel</groupId>
            <artifactId>subclass</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

Und die Klasse darin dann:

import org.daniel.StringGetter;

public class UseSub {

    public static void main(String[] args) {
        StringGetter sub = new StringGetter();
        System.out.println(sub.getSubstring());
    }
}

Witzigerweise hat das gestern nicht funktioniert und heute morgen geht es. Aber grundsätzlich ist das der Ansatz, den ich dann verfolgen möchte. Also ein Projekt, dann da drin mehrere "Helper" Module, die ständig benötigte Funktionen sammeln und dann noch jede Menge Projekte (Module), die Aufgaben erfüllen und dafür zum Teil die "Helper" verwenden.
Und in der erzeugten jar erwarte ich, dass der Helper eingebettet ist, da es ja auch manchmal etwas mit Versionierung zu tun hat.

Erklärt es das Beispiel? Und ist der Ansatz überhaupt "gut"?

 

[DaBe1812]

So, heute in der Firma ein etwas konkreteres Projekt. Aufbau ist ähnlich. Die POM vom Helper-Modul:

<?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">
    <parent>
        <artifactId>root</artifactId>
        <groupId>intern.proips</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>ProIPSMail</artifactId>

    <dependencies>
        <dependency>
            <groupId>javax.mail</groupId>
            <artifactId>javax.mail-api</artifactId>
            <version>1.6.2</version>
        </dependency>
    </dependencies>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

</project>

Der Zugehörige Code (gekürzt):

    public void send() throws Exception {
        Session session = getSessionForMail();

        MimeMessage message = new MimeMessage(session);
        message.setFrom(new InternetAddress(MAIL_SENDER));
        message.setSubject(subject);
        addRecipients(message);

        MimeMultipart mimeMultipart = new MimeMultipart();

        MimeBodyPart mailText = new MimeBodyPart();
        mailText.setText(text);
        mimeMultipart.addBodyPart(mailText);

        for (File file : files) {
            if(file == null) continue;
            MimeBodyPart mbp2 = new MimeBodyPart();
            mbp2.attachFile(file);
            mimeMultipart.addBodyPart(mbp2);
        }

        message.setContent(mimeMultipart);


        Transport.send(message);
    }

Und die POM des aufrufenden Moduls:

<?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">
    <parent>
        <artifactId>root</artifactId>
        <groupId>intern.proips</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>AbgleichVerschrottung</artifactId>

    <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.21.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.21.1</version>
        </dependency>

        <dependency>
            <groupId>intern.proips</groupId>
            <artifactId>ProIPSMail</artifactId>
            <version>LATEST</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

</project>

Und der Code:

import mail.ProIpsMail;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class AbgleichWorker {

    private static final Logger LOG = LogManager.getLogger(AbgleichWorker.class);

    public static void main(String[] args) {
        LOG.info("------ Starte Abgleich ------");

        try {
            ProIpsMail mail = new ProIpsMail();
//            mail.setSubject("Abgleich Verschrottungslager");
//            mail.setMailTo(Arrays.asList("test@test.test"));
//            mail.setFiles(csvFiles);
//            mail.setText(makeText(worker));
//            mail.send();

        } catch (Exception e) {
            LOG.error("Fehler bei der Verarbeitung: ", e);;
        }

        LOG.info("------ Ende Abgleich ------");

    }
}

Der kommt bei der Ausführung zum ersten LOG und kracht danach direkt mit der Meldung, aber nicht aus dem Catch-Block:

Exception in thread "main" java.lang.NoClassDefFoundError: javax.mail.Address
    at AbgleichWorker.main(AbgleichWorker.java:35)
Caused by: java.lang.ClassNotFoundException: javax.mail.Address
    at java.net.URLClassLoader.findClass(URLClassLoader.java:591)
    at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:951)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:896)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:879)
    ... 1 more

 

[KonradN]

Du hast ein Scope compile angegeben. Damit ist die Abhängigkeit zur Laufzeit nicht da. Nimm den Scope raus.

 

[DaBe1812]

Okay, Scope raus, Fehler bleibt. Muss ich evtl. noch was anderes drücken?

 

[KonradN]

Also wenn der Scope bei der Abhängigkeit komplett raus ist und Du es neu gebaut hast, dann die Frage:

• wie baust Du es?
• wie startest Du es, wenn der Fehler kommt?

 

[DaBe1812]

Gute Fragen.
Da ich neu in IntelliJ bin, kann ich die Fragen auch nur schwer beantworten.
Gestartet habe ich über denn netten Play-Button an meine main Methode.
Dabei ist scheinbar im Hintergrund ein ANT-Build gemacht worden, zumindest finde ich diese Ausgabe:

Executing pre-compile tasks...
Loading Ant configuration...
Running Ant tasks...
Running 'before' tasks
Checking sources
Copying resources... [ProIPSMail]
Copying resources... [AbgleichVerschrottung]
Parsing java… [ProIPSMail]
Writing classes… [ProIPSMail]
Checking dependencies… [ProIPSMail]
Dependency analysis found 0 affected files
Updating dependency information… [ProIPSMail]
Adding @NotNull assertions… [ProIPSMail]
Adding pattern assertions… [ProIPSMail]
Adding the Threading Model assertions… [ProIPSMail]
Checking dependencies… [AbgleichVerschrottung]
Dependency analysis found 1 affected files
Updating dependency information… [AbgleichVerschrottung]
Parsing java… [AbgleichVerschrottung]
Writing classes… [AbgleichVerschrottung]
Dependency analysis found 0 affected files
Adding @NotNull assertions… [AbgleichVerschrottung]
Adding pattern assertions… [AbgleichVerschrottung]
Adding the Threading Model assertions… [AbgleichVerschrottung]
Running 'after' tasks
javac 1.8.0_292 was used to compile java sources
Finished, saving caches…
Modules 'ProIPSMail', 'AbgleichVerschrottung' were fully rebuilt due to project configuration/dependencies changes
Executing post-compile tasks...
Loading Ant configuration...
Running Ant tasks...
Synchronizing output directories...
27.11.2023 09:55 - Build completed successfully in 5 sec, 702 ms

Im Zuge von Keep it Simple habe ich mein externes Modul einfach mal als Klasse im Modul verwendet. Dabei habe ich einen Fehler mit dem Mail-Logger bekommen. Nach kurzem Googlen habe ich in Maven die Dependency getauscht auf:

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>javax.mail</artifactId>
    <version>1.6.2</version>
</dependency>

Damit lief der Code mit der internen Klasse und nach der Umstellung im anderen Modul geht das jetzt auch mit dem externen Modul. Ich verstehe den Unterschied nicht, bzw. wo mein Fehler in der Verwendung der Klasse liegt.

Im ursprünglichen Projekt hatte ich nur eine mail.jar verknüpft.

 

[KonradN]

Hast Du noch parallel build.xml Dateien von ant? Wobei IntelliJ gerne sein eigenes System verwendet und nicht Maven verwendet. Die Module von IntelliJ sind aber dann mit den Angaben aus Maven gefüllt - da darf man nur nicht den Fehler machen und in IntelliJ etwas verändern.

Oder hast Du die pom.xml ans Ant Build Ziel hinzugefügt? Das geht auch über das Kontextmenü der pom.xml Datei. Da dann ggf. in dem Ant Toolfenster dies wieder löschen. (So du das nicht aus irgend einem Grund so haben willst...)

Bei Problemen mit IntelliJ habe ich in der Vergangenheit einfach das Projekt in IntelliJ geschlossen und dann die IntelliJ Dateien komplett gelöscht (Die sind bei mir auch komplett nicht in der Versionsverwaltung drin) und dann hat IntelliJ beim nächsten Öffnen des Projekts alles neu aus den Maven Projekten generiert. (Aber das ist schon lange nicht mehr vorgekommen). Ebenso interessant ist die Einstellung:
Build, Execution, Deployment -> Build Tools -> Maven -> Runner
Dort gibt es ein "Delegate IDE build/run actions to Maven" mit dem man sowas generell über Maven laufen lässt.
Das kann man also prinzipiell auch nutzen und das dürfte so Probleme auch vermeiden. (Ich nutze es aber nicht, das Problem ist bei mir auch schon sehr lange nicht mehr aufgetreten! War also in 2022er Versionen zuletzt, dass ich da so drastische Schritte machen musste...)

Im ursprünglichen Projekt hatte ich nur eine mail.jar verknüpft.

Hier verstehe ich die Aussage nicht. Du hast uns ja die POM gezeigt und da war die Abhängigkeit zu javax.mail enthalten. Und Maven behandelt Abhängigkeiten transitiv. Wenn B eine Abhängigkeit zu A hat und C hat dann eine Abhängigkeit zu B, dann hat C auch automatisch eine Abhängigkeit zu A. Daher hattest Du in dem Hauptfenster auch eine entsprechende Abhängigkeit.

Und Abhängigkeiten nur in der pom hinzufügen. Also nicht in den Modul-Settings eine Library hinzu fügen oder so...

Nach dem Ändern der pom.xml (dem herausnehmen des scope): Hast du die pom dann in IntelliJ neu geladen? Dazu erscheint normalerweise so ein kleiner Button oben rechts im Bereich der Code Fenster und Du kannst es über das Maven Toolfenster auch neu laden. Dann erst nimmt IntelliJ die Änderungen an den Dependencies.

Was ich immer gerne mache:
mvn clean package
bzw,
mvn clean install
Das kann man sehr schön in der IDE über das MaVen Toolfenster starten - einfach da auf den Runner gehen und Du kannst die Ziele eingeben, die Du möchtest.

Oder wenn Du es auf der Kommandozeile machen willst: Ich nutze immer gerne den Maven Wrapper. Dazu im Maven Toolfenster einfach mal auf den Runner gehen und wrapper:wrapper als Ziel starten. Das klappt in der Regel in IntelliJ ohne, dass man das wrapper Plugin hinzufügt. Sollte es nicht gehen, dann fügt man den wrapper einmal schnell hinzu. Damit hast Du dann mvnw Scripte im Projekt und Du kannst das Projekt sehr schön auf der Kommandozeile bauen.

Das waren jetzt so ein paar Dinge, die mir so durch den Kopf gegangen sind. Das hängt nicht alles direkt mit der Thematik zusammen - was es evtl. unübersichtlich macht. Mir wäre wichtig die Nachfrage zu den Abhängigkeiten und was Du da genau gemacht hast.

 

[KonradN]

Ach so - ganz vergessen: Im Maven Toolfenster hast Du einen Knopf, der die Abhängigkeiten schön als Diagram anzeigt. Und du hast die Dependencies auch in dem Toolfenster und transitive Abhängigkeiten siehst Du, wenn Du da die Elemente aufklappst. Das könnte auch interessant sein, da einmal bewusst drauf zu schauen.

 

[DaBe1812]

Das war jetzt mal ein ausführlicher Eintrag, der mich an die Hand nimmt

Also:
es sollte kein ANT-File geben, da ich das Projekt nicht importiert habe, sondern neu aufgesetzt und lediglich den Code kopiert habe. Schlechte Erfahrungen mit Migrationen sei dank. Im Modul habe ich als Buildsystem im Wizard MAVEN ausgewählt. Ich muss dazu sagen, dass beim MAVEN hier in der Firma dazu kommt, dass es einen Firmeneigenen NEXUS gibt und deswegen die MAVEN-Properties nicht ganz Standard sind. Um da aber die Unterschiede benennen zu können, fehlt mir völlig die Expertise.
Die Toolfenster kannte ich noch garnicht, aber in dem für ANT ist alles leer. Und ich will grundsätzlich nicht mehr über ANT builden, da es hier in der Firma Automatismen gibt, die nur mit Maven funktionieren.
In den Runner-Einstellungen war der Haken bei "Delegate IDE build/run actions to Maven" nicht gesetzt, den habe ich jetzt mal rein genommen, oder?

Im ursprünglichen Projekt hatte ich nur eine mail.jar verknüpft.

Ich glaube hier gibt es ein Missverständnis. Mit ursprüngliches Projekt meine ich das Projekt in Eclipse, ist ja tatsächlich ein "ganz anderes" Ding, weil ich in IntelliJ alles neu gemacht und nur den Code rüber kopiert habe. Damals habe ich noch alle Klassen aus dem Maven Central runtergeladen, oder aus vorherigen Projekten verwendet. Also wäre es auch möglich, dass die mail.jar sowas von outdatet ist, dass es gabz gut war mal was anderes zu verwenden.

Den Button oben in der POM hatte ich noch nicht gesehen, witzig.

Mit dem Maven-Fenster musst du mir mal auf die Sprünge helfen. Was muss ich da drücken, damit er die Befehle ausführt?
Und ich finde in dem Fenster keinen Runner, was muss ich da machen?

Der Dependency-Baum ist ja ein richtig lustiges Ding.
Da muss ich später, wenn ich das Server-Projekt migriere sowieso mal schauen, aktuell musste ich mir ja alle Dependencies selbst auflösen, da werde ich dann später nur noch die eigentlichen Module brauchen.

 

[KonradN]

In dem Maven Toolfenster kannst Du direkt einiges mit den Einträgen machen - also Profile (so du welche hast) auswählen, Lifecycle per Doppelklick starten (wenn Du nur ein Ziel willst wie clean oder package oder install ....) und Du kannst Du Plugins und Dependencies durchgehen.

Aber oberhalb hast Du mehrere Knöpfe und ich meinte den "Execute Maven Goal" Knopf. Dann kannst Du einen mvn Befehl eingeben, den Du ausführen möchtest und er zeigt Dir auch diverse Vorschläge und zuletzt ausgeführte Befehle.

Und das Ausführen über die IDE verändert sich nicht. Da nutzt Du weiterhin die Wege, die Du schon kennst. Maven ist halt wirklich nur das Build Tool. Es gibt zwar auch Plugins für die Ausführung und dann kannst Du mit Maven das Projekt ausführen, aber die sind in der Regel sehr spezifisch wie z.B. bei JavaFX (da gibt es das openjfx Plugin mit der Möglichkeit, die Anwendung auszuführen) oder bei Quarkus hast Du auch die Möglichkeit, das über Maven zu starten und so ... Das ist aber keine generische Maven Möglichkeit.

Aber sowas kannst Du Dir natürlich auch bauen - Dependencies kopieren und dann über ein Plugin einfach entsprechend den Java Prozess starten. Aber dann willst Du ja auch den Debugger haben und und und ... Das ist den Aufwand (meiner Meinung nach) nicht wert.

 

[DaBe1812]

Alles klar, Button habe ich gefunden. Jetzt kommen aber zwei Fehler:
Wenn ich im Maven Fenster im resultierenden Modul auf Lifecycle->compile (oder anderes) gehe, dann kommt folgender Fehler:

Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ProIpsMail/1.0-SNAPSHOT/ProIpsMail-1.0-SNAPSHOT.pom
[WARNING] The POM for intern.proips.helper:ProIpsMail:jar:1.0-SNAPSHOT is missing, no dependency information available
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ProIpsDbConnector/1.0-SNAPSHOT/maven-metadata.xml
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ProIpsDbConnector/1.0-SNAPSHOT/ProIpsDbConnector-1.0-SNAPSHOT.pom
[WARNING] The POM for intern.proips.helper:ProIpsDbConnector:jar:1.0-SNAPSHOT is missing, no dependency information available
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ConfigReader/1.0-SNAPSHOT/maven-metadata.xml
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ConfigReader/1.0-SNAPSHOT/ConfigReader-1.0-SNAPSHOT.pom
[WARNING] The POM for intern.proips.helper:ConfigReader:jar:1.0-SNAPSHOT is missing, no dependency information available
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ProIpsMail/1.0-SNAPSHOT/ProIpsMail-1.0-SNAPSHOT.jar
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ConfigReader/1.0-SNAPSHOT/ConfigReader-1.0-SNAPSHOT.jar
Downloading from nexus: http://nexus.intern:8081/nexus/content/groups/public/intern/proips/helper/ProIpsDbConnector/1.0-SNAPSHOT/ProIpsDbConnector-1.0-SNAPSHOT.jar

Das sind meine internen Abhängigkeiten, die da angemeckert werden.

Wenn ich über den Execute Maven Goal Button gehe und nehme z.B. mvn clean package dann kommt derselbe Fehler, wenn ich oben das Modul einstelle, welches ich builden möchte.

Muss ich da evtl. noch einstellen, welche Module er nicht auf unserem Nexus suchen soll?

Testweise ausführen geht jetzt irgendwie gerade auch nicht, ich denke es liegt daran, dass er nicht sauber builden kann, es fehlt nämlich im Modul der Target-Ordner.

 

[KonradN]

Also erst einmal sind das nur Warnungen und keine Fehler. Im Repository ist in der Regel nicht nur das eigentliche JAR sondern es ist noch die POM dabei um transitive Abhängigkeiten zu kennen und es können sich auch Sourcen, JavaDoc und so dort finden.

So es keine transitiven Abhängigkeiten gibt oder Du diese manuell hinzu gefügt hast, sollte an der Stelle alles ok sein.

 

[DaBe1812]

Also in dem LOG zeigt er es als Warning an, aber im Baum ist es ein Error und es gibt ja auch keinen Target-Ordner und die JAR-Datei fehlt.

Could not find artifact intern.proips.helper:ProIpsMail:pom:1.0-SNAPSHOT in nexus (http://nexus.intern:8081/nexus/content/groups/public/)

Das ist unter anderem die Ausgabe.

 

[KonradN]

Das ist jetzt auch eine andere Meldung als die, die Du zuerst gezeigt hast. Denn Du hast nur Dinge gezeigt, die erst einmal ok sind (Download Hinweise und paar Warnungen zu fehlenden POM Dateien).

Das ist jetzt tatsächlich ein Fehler, denn ein Artifact kann nicht gefunden werden. Da ist dann die Frage, wo die Abhängigkeit ist. Die Abhängigkeiten müssen ja irgendwo zur Verfügung stehen.

Wenn es andere, lokale Projekte sind, dann kannst Du diese bauen. Mit mvn install wird das Ergebnis im local Repository gespeichert.

Wenn Du die jar Dateien hast, dann kannst Du diese mit maven auch direkt in ein Repository schreiben:

mvn install:install-file \
   -Dfile=<path-to-file> \
   -DgroupId=<group-id> \
   -DartifactId=<artifact-id> \
   -Dversion=<version> \
   -Dpackaging=<packaging> \
   -DgeneratePom=true

(ggf. noch mit Angabe des Repositories wenn es nicht das local repository sein soll).

Was ich schon gemacht habe: Ich habe im Projekt ein Repository mit angelegt und dort jar Dateien installiert und dann in Maven das Repositoy mit angegeben. Das ist aber in der Regel keine gute Idee.

Was Du auch machen kannst, ist ein eigenes Repository anlegen (Also mit http Schnittstelle und so). Tools wie Reposilite könnten da genutzt werden und das hätte den Vorteil, dass es im Team gemeinsam verwendet werden kann.

 

[DaBe1812]

Also scheinbar muss ich IntelliJ einfach öfter zu machen.
Ich hab nochmal mvn clean install -U (ergoogelt) ausprobiert, da hab ich dann eine verdopplung der Abhängigkeiten bekommen, das hab ich dann auch nochmal ergooglelt und es lag daran, dass ich meinen Baum angepasst habe und dann in der root und in der helper POM die module doppelt waren.
Danach konnte ich einfach im meiner main-Methode wieder auf Play drücken und dann hat er alle dependencies automatisch gebuildet und die Anwendung ausgeführt.
Gestern hat er auf dem Play-Button einfach nichts gemacht.
Repository wird der nächste Spaß, wenn wir von Subversion auf GIT umsteigen, aber bis dahin baue ich die ganzen Einzel-Projekte in Eclipse in ein Root-Projekt in IntelliJ.

Am meisten Spaß habe ich gerade am vereinheitlichen von den ganzen Unterprozeduren. Außerdem musste ich von einer ini-config auf eine yaml wechseln, weil im lokalen Nexus ini4j gefehlt hat und ich zu faul war es zu Fuß zu machen. Aber YAML sieht sowieso viel professioneller und moderner aus.

Also aktuell läuft das Programm und ich hoffe, dass ich die jars auch später außerhalb von IntelliJ verwenden kann. Das einzige, was mir noch "aufgefallen" ist. Ich habe versucht eine Datei in "./datei.yaml" zu lesen und diese hat er aber nicht, wie erwartet im root von meinem Modul gesucht, sondern im root vom root.

 

[DaBe1812]

So, ich hab endlich wieder Zeit mich um das Projekt zu kümmern.
Ich habe jetzt mal im Maven Fenster das m gedrückt, dann oben das Modul ausgewählt, welches ich letztendlich haben möchte und dann mit
mvn clean install
kompiliert (?).
Ic hhabe im target-Ordner dadurch auch eine jar erhalten.
Hier mal das Ergebnis:

C:\Werkbank\JW\java\OpenJDK\bin\java.exe -Dmaven.multiModuleProjectDirectory=C:\Projekte\IntelliJ_Workspace\root -Dmaven.home=C:\Werkbank\UW-22.1.0\intellij\plugins\maven\lib\maven3 -Dclassworlds.conf=C:\Werkbank\UW-22.1.0\intellij\plugins\maven\lib\maven3\bin\m2.conf -Dmaven.ext.class.path=C:\Werkbank\UW-22.1.0\intellij\plugins\maven\lib\maven-event-listener.jar -javaagent:C:\Werkbank\UW-22.1.0\intellij\lib\idea_rt.jar=61271:C:\Werkbank\UW-22.1.0\intellij\bin -Dfile.encoding=UTF-8 -classpath C:\Werkbank\UW-22.1.0\intellij\plugins\maven\lib\maven3\boot\plexus-classworlds-2.6.0.jar;C:\Werkbank\UW-22.1.0\intellij\plugins\maven\lib\maven3\boot\plexus-classworlds.license org.codehaus.classworlds.Launcher -Didea.version=2022.1.4 --update-snapshots -s C:\Werkbank\UW-22.1.0\apache-maven-3.8.6\conf\settings.xml clean install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] root                                                               [pom]
[INFO] helper                                                             [pom]
[INFO] ProIpsMail                                                         [jar]
[INFO] ConfigReader                                                       [jar]
[INFO] ProIpsDbConnector                                                  [jar]
[INFO] CommandConnector                                                   [jar]
[INFO] FileUtils                                                          [jar]
[INFO] ProIpsPrueftool                                                    [pom]
[INFO] AbgleichVerschrottung                                              [jar]
[INFO]
[INFO] -------------------------< intern.proips:root >-------------------------
[INFO] Building root 1.0-SNAPSHOT                                         [1/9]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ root ---
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ root ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\pom.xml to C:\Projekte\m2\repository\intern\proips\root\1.0-SNAPSHOT\root-1.0-SNAPSHOT.pom
[INFO]
[INFO] ------------------------< intern.proips:helper >------------------------
[INFO] Building helper 1.0-SNAPSHOT                                       [2/9]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ helper ---
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ helper ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\pom.xml to C:\Projekte\m2\repository\intern\proips\helper\1.0-SNAPSHOT\helper-1.0-SNAPSHOT.pom
[INFO]
[INFO] ------------------< intern.proips.helper:ProIpsMail >-------------------
[INFO] Building ProIpsMail 1.0-SNAPSHOT                                   [3/9]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ProIpsMail ---
[INFO] Deleting C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsMail\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ProIpsMail ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ProIpsMail ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsMail\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ ProIpsMail ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsMail\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ ProIpsMail ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ ProIpsMail ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ ProIpsMail ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsMail\target\ProIpsMail-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ ProIpsMail ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsMail\target\ProIpsMail-1.0-SNAPSHOT.jar to C:\Projekte\m2\repository\intern\proips\helper\ProIpsMail\1.0-SNAPSHOT\ProIpsMail-1.0-SNAPSHOT.jar
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsMail\pom.xml to C:\Projekte\m2\repository\intern\proips\helper\ProIpsMail\1.0-SNAPSHOT\ProIpsMail-1.0-SNAPSHOT.pom
[INFO]
[INFO] -----------------< intern.proips.helper:ConfigReader >------------------
[INFO] Building ConfigReader 1.0-SNAPSHOT                                 [4/9]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ConfigReader ---
[INFO] Deleting C:\Projekte\IntelliJ_Workspace\root\helper\ConfigReader\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ConfigReader ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ConfigReader ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 6 source files to C:\Projekte\IntelliJ_Workspace\root\helper\ConfigReader\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ ConfigReader ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Projekte\IntelliJ_Workspace\root\helper\ConfigReader\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ ConfigReader ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ ConfigReader ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ ConfigReader ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\helper\ConfigReader\target\ConfigReader-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ ConfigReader ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\ConfigReader\target\ConfigReader-1.0-SNAPSHOT.jar to C:\Projekte\m2\repository\intern\proips\helper\ConfigReader\1.0-SNAPSHOT\ConfigReader-1.0-SNAPSHOT.jar
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\ConfigReader\pom.xml to C:\Projekte\m2\repository\intern\proips\helper\ConfigReader\1.0-SNAPSHOT\ConfigReader-1.0-SNAPSHOT.pom
[INFO]
[INFO] ---------------< intern.proips.helper:ProIpsDbConnector >---------------
[INFO] Building ProIpsDbConnector 1.0-SNAPSHOT                            [5/9]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ProIpsDbConnector ---
[INFO] Deleting C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsDbConnector\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ProIpsDbConnector ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ProIpsDbConnector ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 5 source files to C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsDbConnector\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ ProIpsDbConnector ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsDbConnector\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ ProIpsDbConnector ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ ProIpsDbConnector ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ ProIpsDbConnector ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsDbConnector\target\ProIpsDbConnector-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ ProIpsDbConnector ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsDbConnector\target\ProIpsDbConnector-1.0-SNAPSHOT.jar to C:\Projekte\m2\repository\intern\proips\helper\ProIpsDbConnector\1.0-SNAPSHOT\ProIpsDbConnector-1.0-SNAPSHOT.jar
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\ProIpsDbConnector\pom.xml to C:\Projekte\m2\repository\intern\proips\helper\ProIpsDbConnector\1.0-SNAPSHOT\ProIpsDbConnector-1.0-SNAPSHOT.pom
[INFO]
[INFO] ---------------< intern.proips.helper:CommandConnector >----------------
[INFO] Building CommandConnector 1.0-SNAPSHOT                             [6/9]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ CommandConnector ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ CommandConnector ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ CommandConnector ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 4 source files to C:\Projekte\IntelliJ_Workspace\root\helper\CommandConnector\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ CommandConnector ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Projekte\IntelliJ_Workspace\root\helper\CommandConnector\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ CommandConnector ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ CommandConnector ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ CommandConnector ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\helper\CommandConnector\target\CommandConnector-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ CommandConnector ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\CommandConnector\target\CommandConnector-1.0-SNAPSHOT.jar to C:\Projekte\m2\repository\intern\proips\helper\CommandConnector\1.0-SNAPSHOT\CommandConnector-1.0-SNAPSHOT.jar
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\CommandConnector\pom.xml to C:\Projekte\m2\repository\intern\proips\helper\CommandConnector\1.0-SNAPSHOT\CommandConnector-1.0-SNAPSHOT.pom
[INFO]
[INFO] -------------------< intern.proips.helper:FileUtils >-------------------
[INFO] Building FileUtils 1.0-SNAPSHOT                                    [7/9]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ FileUtils ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ FileUtils ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ FileUtils ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\Projekte\IntelliJ_Workspace\root\helper\FileUtils\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ FileUtils ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Projekte\IntelliJ_Workspace\root\helper\FileUtils\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ FileUtils ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ FileUtils ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ FileUtils ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\helper\FileUtils\target\FileUtils-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ FileUtils ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\FileUtils\target\FileUtils-1.0-SNAPSHOT.jar to C:\Projekte\m2\repository\intern\proips\helper\FileUtils\1.0-SNAPSHOT\FileUtils-1.0-SNAPSHOT.jar
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\helper\FileUtils\pom.xml to C:\Projekte\m2\repository\intern\proips\helper\FileUtils\1.0-SNAPSHOT\FileUtils-1.0-SNAPSHOT.pom
[INFO]
[INFO] -------------------< intern.proips:ProIpsPrueftool >--------------------
[INFO] Building ProIpsPrueftool 1.0-SNAPSHOT                              [8/9]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ProIpsPrueftool ---
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ ProIpsPrueftool ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\pom.xml to C:\Projekte\m2\repository\intern\proips\ProIpsPrueftool\1.0-SNAPSHOT\ProIpsPrueftool-1.0-SNAPSHOT.pom
[INFO]
[INFO] -----------< intern.proips.prueftool:AbgleichVerschrottung >------------
[INFO] Building AbgleichVerschrottung 1.0-SNAPSHOT                        [9/9]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ AbgleichVerschrottung ---
[INFO] Deleting C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\AbgleichVerschrottung\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ AbgleichVerschrottung ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ AbgleichVerschrottung ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 4 source files to C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\AbgleichVerschrottung\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ AbgleichVerschrottung ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\AbgleichVerschrottung\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ AbgleichVerschrottung ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ AbgleichVerschrottung ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ AbgleichVerschrottung ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\AbgleichVerschrottung\target\AbgleichVerschrottung-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ AbgleichVerschrottung ---
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\AbgleichVerschrottung\target\AbgleichVerschrottung-1.0-SNAPSHOT.jar to C:\Projekte\m2\repository\intern\proips\prueftool\AbgleichVerschrottung\1.0-SNAPSHOT\AbgleichVerschrottung-1.0-SNAPSHOT.jar
[INFO] Installing C:\Projekte\IntelliJ_Workspace\root\ProIpsPrueftool\AbgleichVerschrottung\pom.xml to C:\Projekte\m2\repository\intern\proips\prueftool\AbgleichVerschrottung\1.0-SNAPSHOT\AbgleichVerschrottung-1.0-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for root 1.0-SNAPSHOT:
[INFO]
[INFO] root ............................................... SUCCESS [  0.426 s]
[INFO] helper ............................................. SUCCESS [  0.042 s]
[INFO] ProIpsMail ......................................... SUCCESS [  1.823 s]
[INFO] ConfigReader ....................................... SUCCESS [  0.469 s]
[INFO] ProIpsDbConnector .................................. SUCCESS [  0.695 s]
[INFO] CommandConnector ................................... SUCCESS [  0.559 s]
[INFO] FileUtils .......................................... SUCCESS [  0.173 s]
[INFO] ProIpsPrueftool .................................... SUCCESS [  0.036 s]
[INFO] AbgleichVerschrottung .............................. SUCCESS [  0.741 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.113 s
[INFO] Finished at: 2024-01-10T13:34:06+01:00
[INFO] ------------------------------------------------------------------------

Process finished with exit code 0

Also sah für mich erstmal gut aus.
1. Problem war, dass ich beim ausführen folgende Meldung bekommen habe:

Fehler: Hauptklasse java.AbgleichVerschrottung konnte nicht gefunden oder geladen werden

Hab ich mir erstmal schnell zusammengegoogelt und in der MANIFEST.MF die Main-Class gesetzt. Dabei habe ich mir das Paket mal angeschaut und festgestellt, dass da drin nur die eigenen Klassen sind. Alles, was ich erwartet hätte, dass es die POM hinzufügt hat gefehlt.
So kam es dann erwartungsgemäß zu folgender Fehlermeldung:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/logging/log4j/LogManager
        at AbgleichVerschrottung.<clinit>(AbgleichVerschrottung.java:15)
Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager
        at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        ... 1 more

Also, wie muss ich jetzt Maven ausführen, damit ich als Ergebnis eine jar erhalte, die ich einfach auf einen anderen Rechner schieben kann und die dann da läuft?

 

[LimDul]

Da gibt es mehrere Möglichkeiten. Eine wäre fat-jar, das baut dir ein JAR, was alle Abhängigkeiten drin hat.
Eine andere wäre jpackage, das baut dir eine Ausführbare Datei inkl. jdk.

Ansonsten kann @KonradN da noch mehr zu den verschiedenen Möglichkeiten erzählen.

 

[KonradN]

Hab ich mir erstmal schnell zusammengegoogelt und in der MANIFEST.MF die Main-Class gesetzt.

Da wäre erst einmal meine Frage: Wie hast Du das gemacht? Ich hoffe, in dem Du in der pom.xml ein plugin konfiguriert hast (z.B. das jar Plugin). Das nur am Rande - nicht dass Du da DIE MANIFEST.MF in den Ressources hinzu gefügt hast

Also, wie muss ich jetzt Maven ausführen, damit ich als Ergebnis eine jar erhalte, die ich einfach auf einen anderen Rechner schieben kann und die dann da läuft?

Das würde am einfachsten mit dem shade Plugin gehen. Das erstellt - wie von @LimDul bereits erwähnt - eine fat-jar.

Dies ist aber nicht mehr der bevorzugte Weg zur Weitergabe. Das Problem ist dabei halt, dass eine passende Java Installation vorausgesetzt wird und das ist halt etwas, das sehr schwer zu supporten ist. Daher gab es schon relativ zeitnah Lösungen, um das zu umgehen und Tools wie launch4j waren sehr verbreitet.

Mit Java 9 wurde JLink eingeführt und mit Java 14 (??) JPackage. Das ist eine weitere Lösung wie von @LimDul bereits erwähnt und die aus meiner Sicht bevorzugte Weise um etwas zu bauen, dass man dann weiter geben kann. Dabei ist wichtig: Es wird für die eigene Plattform ein Image gebaut. Also wenn man für die üblichen Plattformen einen Download anbieten will, dann wird das etwas umständlicher.

Das Ganze kann man relativ einfach mit einbinden in die pom.xml. In kneitzel/JavaMavenApp (github.com) kannst Du ein Beispiel Projekt finden. Das Bauen des Images ist im Profil Image hinterlegt mit der Konfiguration und den notwendigen AddOns.

 

[LimDul]

Eine weitere Möglichkeit - die hier aber eher Overkill ist, wäre Docker. Sprich, man baut einen Docker Container der die Anwendung enthält. Ob das nun ein Fat-Jar ist oder alle Jars einzelnen und ein Aufruf von java -jar xy -cp PfadZuAllenAbhängigkeiten etc. ist dabei erst mal egal.

Ich glaube das ist im privaten Bereich Overkill - kann aber in professioneller Entwicklung durchaus eine Lösung sein, weil mit dem Docker-Container ist man Betriebssystemsunabhängig und kann es überall betreiben (Vorausgesetzt eine Docker-Umgebung ist installiert).

Für Client Anwendungen in der Regel nicht geeignet, aber für Server-Anwendungen geht der Weg vermehrt in diese Richtung.

 

[DaBe1812]

Okay, da stelle ich fest, dass ich gerade ein wenig oldschool unterwegs bin. Bisher war das so, dass wir mit ant das jar gebaut haben incl. aller dependencies und dann auf dem Prod-Server das ganze mittels einer cmd ausgeführt haben etwa so:

d:
cd \Austausch\DBE
java -jar AbgleichVerschrottung.jar

Die cmd konnten wir auch immer in die Windows Aufgabenplanung einbinden. Dank rumprobieren habe ich meine POM bereits erweitert gehabt:

<?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">
    <parent>
        <artifactId>ProIpsPrueftool</artifactId>
        <groupId>intern.proips</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <groupId>intern.proips.prueftool</groupId>
    <artifactId>AbgleichVerschrottung</artifactId>

    <dependencies>
        <!-- meine dependencies -->
    </dependencies>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>3.6.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>AbgleichVerschrottung</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Wenn ich dann mvn clean compile assembly:single ausgeführt habe, dann wurde mir eine jar erzeugt mit ca. 8MB und dieses ließ sich eben Problemlos mit der cmd ausführen.
In der Jar sieht es zwar recht wüst aus, hab aber mal in die "alte" ant-jar geschaut, da ist es ähnlich.

Die Docker-Lösung ist zwar nicht unbedingt overkill, aber leider haben wir keine Docker-Umgebung auf dem Prod-Server.

Die Lösung mit dem implementierten JRE klingt spannend. Ist das dann eine Standalone exe? Ich habe nämlich aktuell das Problem, dass bei uns Java8 raus soll, aber auf den Prod-Servern erst im laufe des ersten Quartals Java17 kommen soll, also muss ich aktuell noch alles in Java8 bauen, damit es auf den Servern läuft.

 

[KonradN]

Die Lösung mit dem implementierten JRE klingt spannend. Ist das dann eine Standalone exe? Ich habe nämlich aktuell das Problem, dass bei uns Java8 raus soll, aber auf den Prod-Servern erst im laufe des ersten Quartals Java17 kommen soll, also muss ich aktuell noch alles in Java8 bauen, damit es auf den Servern läuft.

Wenn Du unter Standalone exe verstehst, dass nur die exe Datei benötigt wird und sonst nichts, dann nein. Du bekommst halt ein sogenanntes Image. Du hast also eine Verzeichnisstruktur und in dieser kann man die JRE auch erkennen.

Wenn Du aber nur meintest, dass Du etwas bekommst, das in sich komplett ist und keine andere Software (wie eine JRE) auf dem Server braucht, dann ist das richtig. Du hast wirklich alles, was Du brauchst und du musst auf dem Rechner nichts anderes installieren. Bereits installierte Dinge stören aber auch (in der Regel) nicht, d.h. wenn Du mit Java 17 etwas baust, dann kann da jemand andere Java Versionen wie Java 21 installieren ohne dass es die Anwendung interessiert.

 

[DaBe1812]

Das klingt doch nach etwas, das ich brauchen könnte. Und das finde ich in deinem angehängten Link?

 

[KonradN]

Ja, da ist das mit drin. In dem GitHub Projekt habe ich mal versucht, die Dinge zusammen zu stellen, die meiner Meinung nach in ein Projekt gehören.

Also so Dinge wie

• statische Codeanalyse - hier bin ich aber inzwischen etwas am überlegen, ob SonarLint in der Entwicklungsumgebung nicht ausreichen könnte.
• Bau von Images (-DImage Parameter)
• Bau mit GraalVM (-DGraalVM) - Das setzt aber eine komplette Entwicklungsumgebung für die Plattform voraus. Aber da hast Du dann am Ende tatsächlich etwas, das mehr in Richtung einer einzelnen EXE geht.

Man kann da durchaus unterschiedlicher Meinung sein, aber bei Maven hat man den Vorteil, dass man Dinge sehr leicht "klauen" kann. Und das mit dem Image ist sehr schön zusammen gefasst. Du kannst also die plugins mit der Konfiguration da sehr gut heraus kopieren.

 

[DaBe1812]

Hab gestern mal in die pom.xml "schnell" reingeschaut, aber auch jetzt beim ordentlichen schauen stelle ich fest, dass ich mit POMs einfach noch nicht so viel anfangen kann. Ich habe jetzt erstmal ganz viel kopiert aus deiner POM.
An manchen Stellen konnte ich meine POM sinnvoll ergänzen.
Den Reporting-Block habe ich erstmal weggelassen, aber wenn ich deine Beschreibung richtig verstanden habe, dann klingt das spannend, dass dort Codeanalysen durchgeführt werden.
Lombock hat mich in den Dependencies verwirrt, ich dachte das erledigt nur so ein wenig "Standardarbeit", wie Getter und Setter Erstellung, hatte es leider bisher noch nicht verwendet.
Kopfzerbrechen macht mir, aber auch schon immer, der Build-Block, ich habe schon nicht verstanden, was der macht, den ich weiter oben gepostet habe, aber deiner schießt bei mir sämtliche Sicherungen.
Gibt es dafür irgendwo mal eine Seite, wo man sich da vernünftig einlesen kann?
Oder willst du erklären, was der macht?
Oder was muss ich überhaupt jetzt hinter mvn angeben, damit er mir erstmal eine jar mit den ganzen Ordnern generiert?

 

[KonradN]

Den Reporting-Block habe ich erstmal weggelassen, aber wenn ich deine Beschreibung richtig verstanden habe, dann klingt das spannend, dass dort Codeanalysen durchgeführt werden.

Den reporting Block kannst Du komplett weglassen. Dort geht es nicht um Analysen sondern es wird ein Report erstellt. Die Codeanalyse selbst findet auch in build/plugins statt - dort findet sich zum einen PMD Plugin als auch das Spotbugs Plugin.

Der reporting Block ist auch erst ganz neu hinzu gekommen. Hättest Du vor 2 Tagen oder so geschaut, dann hättest Du den auch nicht vorgefunden.

Lombock hat mich in den Dependencies verwirrt, ich dachte das erledigt nur so ein wenig "Standardarbeit", wie Getter und Setter Erstellung, hatte es leider bisher noch nicht verwendet.

Das ist richtig. Aber die Abhängigkeit ist zur Compile Zeit wichtig, da ja sonst die Annotations nicht verfügbar wären und das Compiler Plugin braucht natürlich auch den enthaltenen "Annotation Prcessor", sprich der Code, der dann den gewünschten Code generiert und hinzu fügt.

Kopfzerbrechen macht mir, aber auch schon immer, der Build-Block, ich habe schon nicht verstanden, was der macht, den ich weiter oben gepostet habe, aber deiner schießt bei mir sämtliche Sicherungen.
Gibt es dafür irgendwo mal eine Seite, wo man sich da vernünftig einlesen kann?
Oder willst du erklären, was der macht?
Oder was muss ich überhaupt jetzt hinter mvn angeben, damit er mir erstmal eine jar mit den ganzen Ordnern generiert?

Grundlagen Maven - das kann man sich anlesen. Relativ kompakt wären da z.B. die Wikipedia Seite von Maven oder der Anhang von meinem JAdventure: https://jadventure.de/Anhang/E2-maven/
Ich habe auch mal versucht, da ein kleines YouTube Video zu dem Thema Maven zu machen, aber das ist aus meiner Sicht eher verunglückt und ich hatte vor, da mal ein besseres, neues zu machen.

Aber unter dem Strich ist da nicht wirklich so viel, das man wissen muss:

• Maven ist dumm und kann eigentlich fast nichts. Alles, was Maven kann / kennt sind 3 Lifecycle (clean, build und site) welche dann bestimmte Phasen / Schritte hat. (Stark vereinfacht ausgedrückt. Natürlich gibt es Basis Funktionalitäten wir das Laden von Abhängigkeiten aus einem Repository und so!)
• Bei Maven musst Du mindestens eine Phase (Oder eine Alternative, die wir jetzt ignorieren) angeben. Wenn eine Phase angegeben wird, dann wird der Lifecycle, zu dem die Phase gehört, bis zu (einschließlich) dieser Phase durchlaufen.
• Funktionalität kommt sonst nur über Plugins.
• Projekte liegen in pom.xml Dateien (POM = Project Object Model) vor.
• Ähnlich wie in Java, wo jede Klasse von einer anderen erbt, ist es auch bei Maven Projekten: Jedes Projekt hat ein Parent POM. Ist kein parent angegeben, so ist es die "Super POM".
• In der Super POM sind paar erste plugins eingebunden (clean, compiler, ...)
• Convention over Configuration - es gibt eine Art Einigung, wo was liegt, wie was gemacht wird und so. Daran sollte man sich halten. Dann muss man a) weniger konfigurieren und b) man kann Konfigurationen einfach kopieren.

Wenn es dann um konkrete Funktionalität geht, dann muss man also sich das Plugin selbst ansehen. Die Dokumentation eines Plugins ist dann dokumentiert.

Die Lifecycle Phasen vom build Lifecyle hat ein paar Dinge, die wichtig sind:
compile - wie zu erwarten war, wird hier der (main) code übersetzt. Vorab gab es aber Phasen, die das Projekt geprüft haben, Sourcen wurden generiert ... all sowas ...
test - die automatischen Tests. Kommt natürlich nach dem compile und es gib noch Phasen dazwischen.
package - hier wird das jar, war, ... gebaut. Das ist also eine gute Möglichkeit, so Du dein Projekt übersetzen willst.
install - hier wird das, was bei package schon gebaut wurde und das danach verifiziert wurde dann in das lokale Repository installiert. Das kann für libraries wichtig sein, wenn Du also eine Library entwickelst und diese dann bei Dir einbinden willst, dann wäre bei der library das install wichtig.
deploy wäre noch zu erwähnen. Ggf. willst Du ja das, was Du gebaut hast, auf einem Repository deployen. Das wäre dann in diesem Schritt.

Somit wäre dann ein Aufruf, um alles neu zu bauen ein "mvn clean install".
Hier würde dann erst der clean Lifecycle bis einschliesslich clean laufen (pre-clean, clean) und dann der build lifecycle bis einschliesslich install.

Generell - wenn man sowas mehr in der Tiefe wissen wollte: Es gibt diverse Bücher zu Maven. Aber die Frage ist: braucht man das? Wie viel willst Du mit Maven Projekten machen? Bei Maven ist das wichtig, was die Prinzen besungen haben: "Das ist alles nur geklaut"
==> Wenn Du etwas brauchst, dann schaust Du einmal online und dann hast Du in der Regel direkt etwas, das Du kopieren kannst. Also ganz einfach und trivial. In Projekten hast Du in der Regel oft jemanden wie mich - der macht so Anforderungen dann halt mal eben, wenn diese aufkommen. Und Du hast hier das Forum, wo du kurz fragst und dann hast Du das Projekt auch (So Google / ChatGPT / SO dir das nicht eh schon gegeben haben)

 

[DaBe1812]

Danke für den Link auf deine Seite, jetzt habe ich schonmal mein erstes Problem verstanden:
Ich habe mein Projekt intern in viele Module aufgeteilt, weil ich in den Endgültigen Modulen (also die, aus denen eine JAR wird) immer wieder dasselbe, oder ähnliche Sachen mache.
Jetzt hatte ich, wie oben beschrieben die POM und das mvn erfolgreich ausgeführt und testweise mein jar ausgeführt. Dabei hatte ich Probleme mit dem Exceptionhandling festgestellt und für meine Sub-Module eigene Exceptions erstellt, auf die ich dann ordentlich im Hauptmodul reagieren kann.
Als ich dann wieder builden wollte (ihr werdet es ahnen) knallt der build, weil die Exception nicht bekannt ist.
Dank deinem Artikel weiß ich jetzt welche Fummelei wirklich geholfen hat. Ich muss die geänderten Sub-Module neu mit mvn clean install bauen, dann kennt das Hauptprojekt dann auch die Änderungen.
Dazu erstmal ein paar Fragen:
Kann man die Hilfs-Module irgendwie direkt mitbauen?
Macht es da schon Sinn die Hilfsmodule nicht als Snapshot zu deklarieren, sondern ihnen richtige Versionsnummern zu geben?

Den Rest werde ich versuchen am Wochenende zu lesen, weil warum dein build-Teil so riesig ist, ist mir ja immernoch schleierhaft.

Und mal off-topic, hat einer von euch schon das Maven Versionstool ausprobiert? Sieht spannend aus.

Wenn Du etwas brauchst, dann schaust Du einmal online und dann hast Du in der Regel direkt etwas, das Du kopieren kannst. Also ganz einfach und trivial. In Projekten hast Du in der Regel oft jemanden wie mich - der macht so Anforderungen dann halt mal eben, wenn diese aufkommen. Und Du hast hier das Forum, wo du kurz fragst

Das ist ja erstmal richtig, aber man muss ja auch erstmal wissen, was man fragen will. Ich muss ja erstmal maven ansatzweise verstehen, damit ich weiß, wofür Plugins im build überhaupt notwendig sind.
Das wird dann spannend, wenn ich dieses Jahr das Applicationserver Projekt in IntelliJ und damit nach maven umziehe.

 

[LimDul]

Mal ein paar Random Gedanken - ich würde nicht zu viele Module machen. Oftmals reicht ein commons Modul, was alle deine Hilfsklassen enthält. Du hast ja immer noch packages als Strukturierung. Maven Module die nur aus einer Handvoll Klassen bestehen sind meines Erachtens meistens zu klein geschnitten.

Kann man die Hilfs-Module irgendwie direkt mitbauen?

Klar, wenn du ein Multi-Module Project machst. Siehe https://www.baeldung.com/maven-multi-module bzw. hier: https://maven.apache.org/guides/mini/guide-multiple-modules.html

Du hast dann eine parent Pom und darunter diverse Module. Unsere Anwendung sieht z.B. so aus:

Parent-POM
|-domain (Enthält das Domainenmodell, also die Entitäten)
|-business (Business-Logik)
|-web (UI-Layer)
|-extservices (Angebotene Rest-Services)
|-webapplication (Die eigentliche Webapplication, die alles zusammenbundelt)

Wenn man den parent baut, dann werden auch alle sub-Module gebaut.
Die haben dann auch alle die gleiche Version und referenzieren sich gegenseitig über die {project.version}

Macht es da schon Sinn die Hilfsmodule nicht als Snapshot zu deklarieren, sondern ihnen richtige Versionsnummern zu geben?

Kommt drauf an
Wenn deine Hilfsmodule in verschiedenen Projekten verwendet werden, die auch unterschiedliche Release-Zyklen haben - ja, dann ist es sinnvoll, davon eine fixe Version zu bauen und diese zu referenzieren.

Wenn du sie in verschiedenen Projekten verwendest, aber die gleiche Release-Zyklen haben und von einem Team entwickelt werden, dann kannst du auch SNAPSHOT-Versionen verwenden. Dann sollte man aber auch alle diese Module in der IDE haben und auch zusammen im Jenkins oder welchem CI Tool auch immer bauen.

 

[DaBe1812]

Naja, ich hab die Hilfsmodule nach Aufgabe gegliedert und dann haben die eben so viele Klassen, wie sie haben.

Die grundsätzliche Struktur ist immer sehr ähnlich
Lade Config
Lade Daten aus unserer Hauptanwendung (bzw. deren Datenbank)
Tue Dinge mit den Daten (prüfe die Konsistenz, prüfe gegen andere Anwendungen, importiere Daten aus Dateien)
Schreibe die Ergebnisse zurück in unsere Hauptanwendung
Lege die Ergebnisse als CSV ab
Sende die CSVs per Mail

Also habe ich alles, was redundant in allen Tools ist raus geworfen in externe Module:

• Config laden und bereitstellen
• Daten aus unserer eigenen Datenbank laden und wegschreiben
• Daten aus Fremdanwendungen holen
• CSV erstellen und das gesamte Handling mit Dateien
• Mail versenden

In meinem Kopf war der riesen Vorteil, dass ich beim ersten Modul einen riesigen Aufriss habe, alles in extra Module zu packen und diese so zu bauen, dass sie auch wie eine echte Dependency funktionieren,
aber ab dem zweiten Modul habe ich nur noch evtl. kleine Ergänzungen zu machen, im besten Fall kann ich das Modul einfach direkt nutzen.

Da es sich generell um Standalone Java-Tools handelt ist meine Struktur etwas anders. Da wir demnächst von Subversion auf GIT migriert werden, wollte ich die ganzen Java-Tools gerne in einem Projekt haben

root
- helper
-- configHelper
-- proIpsHelper
-- fileHelper
-- mailHelper
- datenpruefer (ein Tool, welches die darunterliegenden Tools nacheinander ausführt)
-- versionspruefer
-- verschrottungspruefer
-- ippruefer

• scanningimport (eigenes Tool)
• datenexport (auch selbstständig)

Also soll theoretisch root garnicht kompiliert werden, das hat auch keine eigenen Klassen. Helper wird auch nicht kompiliert, aber die Helper darunter müssen quasi bei Änderung installiert werden, damit dann die anderen Tools drauf zugreifen können.

Hoffe das ist anschaulich.

 

[LimDul]

In der Regel ist das auch so, dass die Parents (bei dir root & helper) gar keinen Code enthalten. Siehe https://www.baeldung.com/maven-multi-module 6.1.
Mit <packaging>pom</packaging> signalisierst du, dass da kein Code enthalten ist.

 

[DaBe1812]

Mit <packaging>pom</packaging> signalisierst du, dass da kein Code enthalten ist.

Das ist en guter Input. Bin am Überlegen doch nochmal das Firmenlaptop auf zu klappen.
D.h. also dass root und helper pom sind, die einzelnen Helper sind jar, der datenpruefer ist jar, aber was sind dann die Untermodule vom Datenprüfer? Auch jar?
Und wenn ich dann helper mit mvn clean install builde, dann werden alle Helper gebaut und ins local repository gelegt?

Maven ist ja richtig spannend.

 

[DaBe1812]

So, war gerade am gucken im Projekt, der Packaging Type ist da, wo es muss, auf POM, bei den anderen hat es gefehlt gehabt.
Dabie ist mir aber aufgefallen, dass ich in jedem Projekt die Java-Version einzeln angeben muss, dass hätte ich gerne über die Root gehandhabt.
Welche Werte werden denn automatisch aus der parent-Pom geholt, wenn sie nicht in der eigenen Pom angegeben sind?
Also die meisten Properties könnte ich theoretisch über die Parent-Pom führen, wenn das gehen würde.
Edit:
Okay, hätte ich erst getestet und dann gefragt, hätte ich es gemerkt. Also Properties, die unten fehlen, werden aus dem Parent geholt.

 

[LimDul]

Genau, in der Regel sollte 80-90% in der parent.pom definiert werden. In den modulen definiert man nur noch die konkreten Abhängigkeiten (wobei man die Versionen dieser Abhängigkeiten am besten im dependencyManagement der parent.pom pflegt) und ggf. Abweichungen/Zusätze, die in der parent.pom nicht sinnvoll sind.

 

[DaBe1812]

Okay, dazu direkt die nächste Frage:
Was ist der Unterschied zwischen DepndencyManagement, oder direkt Dependency im Parent?
Als Beispiel, ich verwende in allen meinen Modulen das Log4J Paket, also warum sollte ich es mit DependencyManagement einbinden?
Dann muss ich ja in jedem Modul nochmal in den Dependencies diese Abhängigkeit hinzufügen.
Bei meinen "Arbeitsklassen" sehe ich das schon eher ein. Da könnte ich einfach alle Helper im Parent hinzufügen, ob das jetzt in jedem Modul genutzt wird, oder nicht, könnte mir egal sein.
Ich könnte es aber auch über DependencyManagement machen und dann in jeder Klasse nur die Module hinzufügen, die ich auch wirklich brauche.
Oder wäre so eine Mischform auch okay, bzw. "guter Stil". Alles, was ich definitiv in allen Modulen brauche, packe ich als Dependency mit rein und alles, von dem ich die Version global regeln will, kommt ins DependencyManagement und wird dann in den Modulen eingebunden, die es wirklich brauchen?

 

[KonradN]

dependencyManagement
Hier kannst Du Dependencies angeben, konfigurieren und so, die aber für diese POM noch nicht eingebunden werden. Es ist sozusagen nur eine Art Konfiguration für die Dependency.
Dies ist sinnvoll, denn dann kannst Du in einer parent POM bereits Dinge vorgeben wie die Version oder ab ggf. auch Konfigurationen wir, dass transitive Abhängigkeiten nicht geladen werden sollen oder ähnliches.

Beispiel: Spring Boot gibt so sehr viele Abhängigkeiten mit an. Das führt dazu, dass du eine Version nur in dem parent Eintrag hast und alle anderen Abhängigkeiten werden dann nur noch mit groupId / artefactId angegeben.

Das Gleiche gilt auch für das pluginManagement.

Ich könnte es aber auch über DependencyManagement machen und dann in jeder Klasse nur die Module hinzufügen, die ich auch wirklich brauche.
Oder wäre so eine Mischform auch okay, bzw. "guter Stil". Alles, was ich definitiv in allen Modulen brauche, packe ich als Dependency mit rein und alles, von dem ich die Version global regeln will, kommt ins DependencyManagement und wird dann in den Modulen eingebunden, die es wirklich brauchen?

Also aus meiner Sicht macht es Sinn, seine Projekte sauber zu halten. Also sozusagen eine Art Clean Code für pom.xml.

So ziehe ich Versionen und vieles an Konfiguration in die Properties. Da sind dann alle Versionen von Dependencies und Plugins definiert aber auch so Dinge wie die main Class, de Java Version u.s.w. (Und zwar separat als java.version und dann kommt der Eintrag für das compiler plugin separat mit ${java.version}!)

Wenn Du dann mit einem eigenen parent Arbeitest, dann ziehe ich da alles rein, was universell ist:

• Dependency Definitionen, so diese nicht zu speziell sind. Also Dependencies, die ich global gesetzt sehe, sind da drin. Und das in der Regel immer in depencencyManagement. In dependency ist in der Regel nichts. Ich habe da aber auch schon lombok rein gepackt - dann muss man das nicht mehr überall angeben. Aber dann sieht man es nicht und wenn ich die child pom sehe, dann will ich die Abhängigkeiten eigentlich sehen....
• Plugin Definitionen - das ist wirklich super für einige universelle Konfigurationen. Das vereinfacht dann sehr vieles und die child POMs können deutlich reduziert werden. Aber auch hier gilt ein ABER: Das sind dann Dinge, die man nicht mehr sieht. Aber das ist in Ordnung, denn das sind in der Regel Dinge, die festgelegt wurden und die dann klar sein. Es ist klar, dass bei dem Shade Plugin die Signaturen nicht übernommen werden. Das ist einmalig dokumentiert und festgelegt und das muss ich nicht mehr sehen. Ebenso wenn das Team sagt: Wir nutzen Lombok. Dann muss ich das in den child POM nicht mehr sehen.

Das ist aber jetzt nur meine Meinung / Sichtweise. Ich habe bezüglich Maven keine besondere Stellung und meine Sichtweise mag - aus mir noch unbekannten Gründen - ganz oder teilweise Unsinnig sein. Daher sind so Erfahrungsaustausche wichtig und ich lese sehr aufmerksam auch die Antworten der Anderen wie z.B. @LimDul.

 

[LimDul]

Persönlich bin ich ein Freund davon, die parent Pom bzgl. echter Dependencys möglichst sauber zu halten. Bei uns ist da fast nix drin - eigentlich nur junit und hamcrest. Denn es gibt extrem wenig was man wirklich überall immer brauchen wird. Ich nehm nochmal unsere Anwendung auf der Arbeit. Klar slf4j braucht man bestimmt immer, oder? Tja - wir haben auch ein Modul extapi, wo nur unser DTO-Modell drin ist, was andere Anwendungen einbinden können. Will ich denen slf4j aufzwingen? Eher nicht.
Und da merkt man es nicht. Vielleicht hat man so ein Projekt am Anfang nicht - dann fügt man es hinzu, lässt die Dependencys leer und hat vergessen, dass über die Parent-Pom was reinkommt. Hat man keine Dependencys in der parent-pom merkt man, wenn einem was fehlt und man hat nur das, was man wirklich braucht. Und da in der Regel die meisten Projekte aus aufeinanderaufbauenden Modulen bestehen (domain => business => web), muss man die Sachen eh nur in den untersten Modulen hinzufügen

 

[DaBe1812]

Okay, POM scheint jetzt zu funktionieren und ich bin jetzt fröhlich am Code refactoren/migrieren. Ich hab es jetzt dann doch mit dependencyManagement gemacht, wegen der Sauberkeit. Alles kompiliert, und ich kann den Code im IntelliJ debuggen.
IntelliJ an sich ist noch eine Umstellung von Eclipse, weil ich ständig auf Funktionen stehe und wie wild F3 drücke und nichts passiert.

Aber noch was anderes: kann mir jemand Lombok erklären? Ich hab das mal zum Spaß ausprobiert wegen dem getter/setter Ersparnis und dem automatischen Einbinden vom Logger. Funktioniert super beim Kompilieren. Aber trotzdem bleibt es beim Entwickeln als Fehler markiert, das macht mich wahnsinnig. Hab ich da was vergessen?

 

[KonradN]

Aber noch was anderes: kann mir jemand Lombok erklären? Ich hab das mal zum Spaß ausprobiert wegen dem getter/setter Ersparnis und dem automatischen Einbinden vom Logger. Funktioniert super beim Kompilieren. Aber trotzdem bleibt es beim Entwickeln als Fehler markiert, das macht mich wahnsinnig. Hab ich da was vergessen?

Du musst in der Entwicklungsumgebung ein PlugIn installieren und aktivieren.

Bei IntelliJ ist das Lombok Plugin standardmäßig aber dabei (seit ein paar Versionen). Daher sollte es eigentlich direkt von Anfang an funktionieren.

Auf der Webseite ist die Installation beschrieben:
IntelliJ IDEA (projectlombok.org)

 

[DaBe1812]

Tja, schade. In unserem NEXUS ist zwar Lombok in einer recht aktuellen Version drin, aber der IntelliJ Marketplace ist beschnitten und da fehlt das Lombok-Plugin. Ganz toll. Naja, dann eben doch die Getter und Setter alle erzeugen lassen.

 

[DaBe1812]

Hi,
muss das doch nochmal aufwärmen, hatte nämlich gestern wieder etwas gesehen.
Ich habe ein Programm fertig gehabt und in der POM hatte ich keinen <build>-teil gehabt. Hatte das Build dann bis compile durchlaufen lassen und auf meinen Prodserver kopiert. Beim Starten der Datei hat er dann angemeckert, dass dem JAR ein Manifest fehlen würde. Außerdem war die Datei nur 68kb groß. Dann habe ich den Build-Teil angehängt, den ich irgendwo aus dem Internet geklaut hatte:

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>3.6.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>HostGastImport</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id> <!-- this is used for inheritance merges -->
                        <phase>package</phase> <!-- bind to the packaging phase -->
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

Damit war die Datei dann fast 7MB groß und ließ sich auch auf dem anderen Server starten.

Und dazu habe ich jetzt noch Fragen.

1. Brauche ich den Teil überhaupt, oder habe ich beim Builden einen Fehler gemacht gehabt?
2. Kann ich den Teil in meine root-Pom packen und bei mainClass einen Platzhalter eintragen, damit er sich die immer aus der Modul-Pom zieht?
3. Das Ergebnis des Builds heißt immer ModulName-1.0-SNAPSHOT-jar-with-dependencies.jar. Kann man das jar-with-dependencies irgendwie unterbinden, damit später einfach nur ModulName-Version.jar entsteht?

 

[KonradN]

Brauche ich den Teil überhaupt, oder habe ich beim Builden einen Fehler gemacht gehabt?

Wenn Du alle Abhängigkeiten in deinem jar File haben willst, dann brauchst Du das Plugin, ja.
(Wobei ich immer zum shade Plugin greife, aber das ist erst einmal egal)

Kann ich den Teil in meine root-Pom packen und bei mainClass einen Platzhalter eintragen, damit er sich die immer aus der Modul-Pom zieht?

Ja, kannst Du. (Einfach mal ausprobieren?)
Wenn Du es im build/plugins hast, dann wird es für alle childs so genommen. Wenn Du es in build/pluginManagement packst, dann kannst Du es in child Projekten einfach per

<plugin>
    <groupid>org.apache.maven.plugins</groupid>
    <artifactId>maven-assembly-plugin</artifactId>
</plugin>

in build/plugins einbinden.

Und hier den Hinweis: Ich würde immer die groupid mit angeben! Ein Artefakt ist immer über groupid/artefactid identifiziert.

Das Ergebnis des Builds heißt immer ModulName-1.0-SNAPSHOT-jar-with-dependencies.jar. Kann man das jar-with-dependencies irgendwie unterbinden, damit später einfach nur ModulName-Version.jar entsteht?

Du solltest den Namen des jar files mit finalName vorgeben können, also innerhalb der configuration Tags etwas wie <finalName>my-cool-app</finalName>. Da ich aber nicht wirklich viel mit dem Plugin arbeite, kann ich mich hier irren. Aber das wäre etwas, das Du einfach mal ausprobieren kannst.

 

[DaBe1812]

Also habe jetzt den Part angepasst:

   <build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>3.6.0</version>
                <configuration>
                    <finalName>${jar.filename}</finalName>
                    <archive>
                        <manifest>
                            <mainClass>${main.class}</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id> <!-- this is used for inheritance merges -->
                        <phase>package</phase> <!-- bind to the packaging phase -->
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

Erstmal seltsam, sobald ich die groupip dazu machen möchte, meckert es mir IntelliJ an, weil der Tag in dem Rahmen nicht erlaubt wäre.

Das Jar hat immernoch den falschen Namen, und es gibt immer zwei, das war mir vorher nicht so aufgefallen, weil ich immer wie wild am builden bin und dachte, das wären "Reste" von vorher.

Die Logausgabe am Ende des Build sieht so aus:

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ HostGastImporter ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\importer\HostGastImporter\target\HostGastImporter-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-assembly-plugin:3.6.0:single (make-assembly) @ HostGastImporter ---
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\importer\HostGastImporter\target\HostGastImporter-1.0-SNAPSHOT-jar-with-dependencies.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Also irgendwie gibt es ein jar-plugin, was diese "kleine" jar erstellt, die aber mit dem von mir gewünschten Namen, und dann das assembly-plugin, was aber einen falschen Namen erzeugt.

 

[KonradN]

Ich hatte das von Hand geschrieben ... da i von id muss gross sein: groupId heisst das Tag.

 

[DaBe1812]

War auch mein Fehler, ich mach das schon wieder zwischen zwei Projekten und hätte auch einfach nochmal gucken können, ob es ein Typo war.
Mein Build sieht mittlerweile so aus:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.6.0</version>
            <configuration>
                <archive>
                    <manifest>
                        <mainClass>${main.class}</mainClass>
                    </manifest>
                </archive>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
            <executions>
                <execution>
                    <configuration>
                        <finalName>${jar.filename}</finalName>
                        <appendAssemblyId>false</appendAssemblyId>
                    </configuration>
                    <id>make-assembly</id> <!-- this is used for inheritance merges -->
                    <phase>package</phase> <!-- bind to the packaging phase -->
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Macht jetzt in etwa was es soll, ich bekomme aber zwei Warnungen:

[INFO] --- maven-assembly-plugin:3.6.0:single (make-assembly) @ HostGastImporter ---
[WARNING] Artifact: intern.proips:HostGastImporter:jar:1.0-SNAPSHOT references the same file as the assembly destination file. Moving it to a temporary location for inclusion.
[INFO] Building jar: C:\Projekte\IntelliJ_Workspace\root\importer\HostGastImporter\target\HostGastImporter-1.0-SNAPSHOT.jar
[WARNING] Configuration option 'appendAssemblyId' is set to false.
Instead of attaching the assembly file: C:\Projekte\IntelliJ_Workspace\root\importer\HostGastImporter\target\HostGastImporter-1.0-SNAPSHOT.jar, it will become the file for main project artifact.
NOTE: If multiple descriptors or descriptor-formats are provided for this project, the value of this file will be non-deterministic!
[WARNING] Replacing pre-existing project main-artifact file: C:\Projekte\IntelliJ_Workspace\root\importer\HostGastImporter\target\archive-tmp\HostGastImporter-1.0-SNAPSHOT.jar
with assembly file: C:\Projekte\IntelliJ_Workspace\root\importer\HostGastImporter\target\HostGastImporter-1.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Die erste verstehe ich, das hat ja etwas mit dem Lifecycle zu tun, aber die zweite müsste ja nicht sein, wenn er die erste jar gar nicht erst erzeugen würde. Kann man das im Build irgendwie überspringen?

 

[DaBe1812]

Hi,
muss nochmal hierher zurück kommen.
Das Projekt funktioniert mittlerweile ganz gut und einzelne Tools sind nach der Migration schon in ihrem IntelliJ Gewand im Einsatz. Allerdings habe ich jetzt noch zwei Fragen:

1. Die Pom-Projekte, also die reinen Sammler für Unterprojekte, die haben von der Automatik trotzdem einen src-Folder bekommen. Kann der nicht gelöscht werden? Ich kann ja sowieso nichts da drin coden, weil es sonst an allen Ecken scheppert.
2. Bei der Versionierung bin ich mir jetzt ein wenig unsicher, alle Module sind ja jetzt noch 1.0-Snapshot, das sollte ja nicht so bleiben. Wenn ich also ein Tool in seinem Entwicklungsstand einsetze, dann muss ich den version-Tag selbst anpassen, da dann eine 1.0 draus machen und wenn ich dann wieder dran rumbastle, dann muss ich das manuell auf 1.1-Snapshot ändern, oder?

 

[KonradN]

Die Pom-Projekte, also die reinen Sammler für Unterprojekte, die haben von der Automatik trotzdem einen src-Folder bekommen. Kann der nicht gelöscht werden? Ich kann ja sowieso nichts da drin coden, weil es sonst an allen Ecken scheppert.

Du kannst das src problemlos löschen. Du musst keine leeren Verzeichnisse vorhalten.

Bei der Versionierung bin ich mir jetzt ein wenig unsicher, alle Module sind ja jetzt noch 1.0-Snapshot, das sollte ja nicht so bleiben. Wenn ich also ein Tool in seinem Entwicklungsstand einsetze, dann muss ich den version-Tag selbst anpassen, da dann eine 1.0 draus machen und wenn ich dann wieder dran rumbastle, dann muss ich das manuell auf 1.1-Snapshot ändern, oder?

Ja, das ist soweit korrekt.

 

[DaBe1812]

Ist das mit der Versionierung auch so weit Usus? Also Snapshot, so lange ich dran rumfiddel, aber sobald es eine Version in die Prod geht, dann Snapshot weg. Und natürlich alle Verwender meiner Klasse müssen dann natürlich auf eine Version "festgesetzt" werden.