Maven: Aufteilung SampleApp für Library

Hallo,

ich entwickle gerade eine kleine Library die ich nachher in einem Repo veröffentlichen möchte. um mir selbst die Entwicklung/ bug fixing etwas leichter zu machen. Hab ich auch schon ein kleine Testanwendung (Sample app) geschrieben in der ich die Lib verwende. Nun stellt sich mir die Frage wie man das mit maven am besten macht.

Bisher hatte ich einfach die App in einem eigenen Package, diese Lösung möchte ich nicht, da ich die Testanwendung nicht als teil der library veröffentlichen möchte. z.B. Hat die App dependencies zu anderen Libs, die die eigentlich lib nicht hat. (konkreter Adapter er Logging API ).

Was ich auch nicht möchte, ist, dass ich, wenn ich eine Kleinigkeit ändere, immer zuvor mvn install aufrufen muss und die Testapp einfach die Lib als dependency hat, da dies meiner Meinung nach debugging erschwert. Z.B. source code zur Laufzeit ändern geht damit gar nicht.

Im Moment hab ich daher ein multi module project gemacht. Die lib ist ein module und die Testapp ist ein anderes die das library-module als dependency hat. Das funktioniert auch so in der Entwicklungsumgebung. Meine Frage ist nun aber, ob das das richtige Vorgehen ist, da ja die Lib am Ende ein komplett eigenständiges ganzes ist.

Ich hoffe es ist klar was ich meine.
Vielen Dank.
AmunRa

Eine Testapp ist auch der falsche Weg. Fast der richtige aber trotzdem falsch. Was du schreiben sollst sind tests :wink: . Dafür bietet dir die maven-projekt-Struktur auch einen extra Test-Ordner an. Dort kannst du dann deine Testspecifischen Klassen und Resourcen halten:

image
(ignorier hier einfach mal den ascii-doc-folder - das ist etwas anderes und ich war zu faul das Projekt zu wechseln zu einem mit ohne dem Ordner)


Edit: nach 2tem lesen bin ich mir nicht mehr so sicher, ob ich dein Problem richtig erkannt habe. Möchtest du einfach nur eine App für die haben zum ausprobieren - oder soll die „TestApp“ auch wirklich als Test der Lib fungieren? (ich hab jetzt auf letzteres geantwortet)

Solange die Library keine Abhängigkeit zum Multi-module-Projek hat, kann die weiter eigenständig veröffentlichet werden.

Ist denn die TestApp rein privat (und lokal) oder soll die auch verbreitet werden?

Ich hab’ inzwischen auch meistens ein Multi-Module-Projekt mit

pom.xml                Bindet praktisch nur die modules aus den Unterverzeichnissen ein
    example-lib/       Verzeichnis für die Library
       pom.xml         POM für die Library
       src/            Sources für die Library
    example-app/       Verzeichnis für die Anwendung
       pom.xml         POM für die Anwendung, mit dependency zur example-lib POM
       src/            Sources für die Anwendung

aaaaber: IIRC habe ich bisher kein Projekt mit dieser Struktur wirklich „released“. Wenn man da ganz oben ein mvn release macht, landet wohl auch die app in der Maven Central. Es sollte eigentlich auch möglich sein, die Lib eigenständig zu deployen (d.h. im example-lib projekt das mvn release zu machen), aber da erinnere ich mich an einige Krämpfe mit dem release plugin: Das erstellt ja einen tag auf GitHub, und spätestens, wenn man eine Struktur hat wie

pom.xml                  
    example-lib-core/
    example-lib-misc/
    example-app/

hat man eben zwei libs, die immer simultan releast und getaggt werden sollten, und das geht wohl nur sinnvoll, wenn man das release ganz oben startet.

Tipps dazu fände ich auch interessant. Die ad-hoc-lösung wäre, die app nicht als module in die top-level-POM aufzunehmen, aber das hat auch wieder Nachteile: Man kann nach dem auschecken nicht einfach starten, sondern muss dann doch erstmal die Libs mit mvn install installieren :confused:

u.U. könnte man die beiden lib-Module noch eine Ebene tiefer schachteln?

Etwa so:

pom.xml                  
libs/
    pom.xml
    example-lib-core/
    example-lib-misc/
example-app/

Hm. Das wäre vielleicht eine Option, die sicher auch AmunRa in Betracht ziehen sollte, für den Fall, dass noch weitere Libs dazukommen. Das ist oft der Fall, wenn man irgendwelche spezifischen Erweiterungen macht, oder auch nur spezifische Implementierungen der API anbietet, die in der Lib steckt - eben sowas wie lib-core, lib-impl-X und lib-impl-Y.

Ich erinnere mich an etwas Gefrickel beim ersten Projekt, wo ich versucht hatte, Lib und Samples zu trennen (und auf den Commit Removed the samples, because Maven wanted it. · javagl/Obj@888efea · GitHub bin ich nicht gerade stolz :frowning: ). Die ganzen Automatismen, die hinter einem mvn release stecken, machen das schwierig. Dass er da die Versionsnummer IN der POM ändert und committed und das ganze dann taggt hat bei mir schon für einiges Fluchen gesorgt: Wenn da irgendwas schiefgeht, muss man den commit und tag „hart“ im Repo löschen, weil er sonst drüber stolpert…

Aber je nachdem, welche Rolle die „sample-app“ spielt (d.h. u.a., ob es unerwünscht ist, dass die in der Maven Central rumflackt oder nicht), gibt es da sicher eine „saubere“ Lösung.

Ja genau das will ich. Ich konkretisieren das einmal. Es geht um eine Lib für neue swing Komponenten.
Für die Funktionalität hab ich natürlich klassische unit Tests, aber manchmal will man die Komponente auch in der Bedienung testen und dazu hab ich eben diese kleine Beispiel Anwendung die eben nicht Teil der lib werden soll.

Sie ist nicht geheim oder so aber sie ist einfach nur zum anschauen der Lib-Funktionalität entwickelt worden und hat daher für niemanden sonst einen Wert.

Wie machst du das sonst?

Für dieses kleine Projekt ist definitiv keine weitere lib geplant. Aber für die weitere Zukunft in anderen Projekten nicht auszuschließen.

Ja genau das ist eben nicht optimal.

Da wäre ich nicht so sicher. Ich persönlich finde, dass samples, die zeigen, wie man eine Library echt verwendet, ein absolutes Killerkriterium sein können, dafür, ob die Library für jemanden einen Nutzen hat. Da gibt es Abstufungen, aber ein MCVE sagt oft mehr als 1000 Seiten JavaDocs…

Naja, das ist sowas wie https://github.com/javagl/Data, das flackt da halt so rum, und ist (bisher) nicht (aber vermutlich bald) in der Central.

Da stimme ich dir zu, deswegen wird das Test Projekt auch auf github veröffentlicht im repository. Was ich aber meinte ist, dass die app im maven central für niemanden einen Wert haben wird. Also keiner wird jemals die test app als dependency benötigen.

Lg

Kommt ein bißchen drauf an. Ich hab’ für solche Fälle in einer Lib, die tatsächlich schon in der Central liegt, einfach diese “Integration Tests” mit ins test-Verzeichnis gepackt: https://github.com/javagl/Viewer/tree/master/viewer-functions/src/test/java/de/javagl/viewer/functions/test

Echte (d.h. automatisierte) “Unit-Tests” sind bei UI-Components ohnehin schwierig, aber … ich spiel’ da ja eh nur rum…