Vermutlich gibt es hier mal wieder keine Antwort, außer “Don’t fight Maven, you will lose”. Aber unter https://github.com/javagl/Obj habe ich den schwerweigenden Fehler gemacht, die POM in ein Unterverzeichnis zu legen.
OH JEH!!! WIE KONNTE ICH NUR?!
Das release plugin funktioniert schlicht nicht mehr. Er taggt das falsche Verzeichnis. Die release-POMs werden nicht mehr eingecheckt. Konventionen sind schön und gut, aber das ist schlicht lächerlich. Jetzt muss ich vermutlich die beiden Verzeichnisse dort wieder trennen, nur weil dieses verkackte Drecks-Maven (und hierbei HABE ich schon auf eine gewählte Ausdrucksweise geachtet!) zu blöd ist, zu wissen, in welchem Verzeichnis es arbeitet.
So ein Krampf. Da kann einem echt die Lust am Entwickeln vergehen. Ich zock’ jetzt ein bißchen.
wass soll ich sagen, wenn man nach Ärger schreit soll man sich nicht wundern wenn man ihn auch bekommt…
Aber wer startet das ach so bescheuerte maven eigentlich?
Ist da vielleicht irgendwo ein jenkins oder hudson, der dem maven vielleicht über den -f Parameter den Pfad zur POM hätte mitgeben sollen?
Ein Verzeichnis erstellen. Nach Ärger schreien. Wie indoktriniert kann man eigentlich sein? Das Verzeichnis, wo die POM drinliegt, ist das Projektverzeichnis, mit allem drum und dran. Auschecken, mvn install und gut. Dass das (ja: bescheuerte!) Maven aber, wenn jemand „mvn release:prepare“ an der Konsole eintippt (obwohl dieser jemand auch schon „„schlau genug““ war, den Pfad zur POM mit anzugeben, und andere Sachen zu machen, die man im Netz zu diesem Thema findet), meint, kackfrech blind und ungeprüft (!) durch das Ausführen irgendwelcher hartverdrahteter Befehle (!) im SCM rumpfuschen zu müssen, ist einfach schlecht - RICHTIG schlecht. Nachdem ich ca. 10 mal das Tag, das er natürlich fleißig erstellt, wieder gelöscht habe, und 10 mal das „-SNAPSHOT“ wieder zur Versionsnummer hinzugefügt habe, und ca. 10 mal mit „reset – hard / push -f“ den Mist, den er im SCM macht, wieder rückgängig gemacht habe, bin ich einfach angefressen. Die Argumentation von „convention over configuration“ erscheint dabei ungefähr so sinnig, wie zu sagen, dass eine .BAT-Datei mit der Zeile „javac MyProgram.java“ ein universelles Build-System ist, solange jeder sich an die „convention“ hält, sein Programm „MyProgram.java“ zu nennen. Polemisch? Ja. Ungerechtfertigt? Nun, ich bin offen für Argumente, warum es unmöglich sein soll, ein Projekt in ein Unterverzeichnis zu packen.
EDIT: Das smiley kann ruhig dableiben. Das passt ja auch irgendwie.
ähm… ich trau ja fast gar nix dazu zu sagen, weil ich doch noch maven-Anfänger bin. aber es gibt doch release:rollback zumindest macht es die Änderungen an den POMs wieder rückgängig, so dass man das nicht händisch machen muss. Die erzeugten Tags werden noch nicht wieder entfernt.
[quote=Marco13]Ein Verzeichnis erstellen. Nach Ärger schreien. Wie indoktriniert kann man eigentlich sein?[/quote]Jetzt bleib mal ganz cool alter…
Das Problem, dass ich Deiner Triade entnahm, ist doch wohl, dass maven im Root-Verzeichnis des Projekts ausgeführt wird und dort - warum auch immer - Mist baut.
Wie wär’s dann mit 'nem Script, dass maven erst mal in dieses Unterverzeichnis schickt?
Das release:rollback hatte ich schon gesehen. Das ändert aber nichts an Tags und GitHub-commits. Ein dryRun bringt bei sowas halt auch keine Einsichten. Er listet nur auf, was er “machen würde”, aber nicht, dass das, was er da machen würde, nicht funktionieren würde. @Timothy_Truckle Das ganze läuft unter Windows. Die entsprechende BAT müßte ich mir erst zusammenfrickeln, aber auch da gehe ich davon aus, dass das eher Probleme verurschen würde.
“Cool bleiben” ist schwierig. Angenommen man hat ein Projekt, das aus mehreren Teilprojekten/Libraries besteht:
Und dieses (IMHO und aus meiner subjektiv-unfundierten Sicht einfache, gute, vernünftige, klare und nahe liegende(!)) Layout macht es unmöglich, eines dieser Projekte in die Maven Central zu bekommen?! Nur weil das Release-Plugin zu blöd ist, mal zu schauen: “Hey, bin ich überhaupt in einem Git-Repo-Verzeichnis?” bevor es (nochmal: blind, ungeprüft und hartverdrahtet!) irgendwelche GIT-Kommandos ausführt?
Dass das an sich ein Krampf ist, ist offensichtlich (link, link, link, link, so viele links, wie man will). Wenn man aber etliche der Lösungsvorschläge ausprobiert, und er jedesmal irgendwelchen Mist macht, und NIE irgendeine Fehlerbehandlung durchführt, sondern immer fleißig Tags und Commits erstellt, die man dann händisch zurücknehmen muss, dann nervt das einfach.
Über meine Versuche, die Kompilierung von nativen libs in den Maven-Prozess zu kriegen, habe ich geflucht, habe das dann aber noch abgetan als “Ja, das passt halt nicht in die Maven-Welt”. Aber dass man mit Maven nichtmal zwei Projekte in ein Repository legen kann ist schlicht lächerlich. Es gibt sicher eine Lösung. BAT-Dateien oder Shell-Scripte (“Write once, run on one system (that hopefully is not a Mac)”), oder absurde Konfigurationseinträge in immer länger und undurchsichtiger werdenen POMs, die mit einer Version vielleicht funktionieren, und mit einer anderen vermutlich schon nicht mehr. Das sollte aber alles nicht nötig sein. Sooo abwegig ist diese Anforderung ja nun wirklich nicht.
Aber nochmal: Ich bin (so angefressen ich auch sein mag) immernoch für Argumente offen:
Dass man mit Maven ein Projekt nicht in ein Unterverzeichnis eines Repos legen kann, ist gut, weil … (?)
Dass man mit Maven nicht zwei zusammengehörende Projekte in einem Repo haben kann, ist gut, weil … (?)
einige Nutzer wollen vielleicht nur ProjektA und andre nur ProjektB. Wenn beide in einem (Git-)Repo liegen, ist man als Nutzer immer gezwungen sich mit beidem auseinander zu setzen. Mich “ärgert” das gelegentlich, wenn ich eigentlich nur eine Kleinigkeit nutzen möchte, aber einen ganzen Rattenschwanz geliefert bekomme. Das ProjektB vielleicht von ProjektA abhängt ist kein Argument. Möchte ich z.B. ProjektB nutzen und ändern, brauche ich auch nur B zu clonen und zu bauen, A kommt dann ja vom (Maven-)Repo (ohne das ich mich darum kümmern müsste).
Erst wenn ich strukturelle Änderungen vornehmen möchte die A und B betreffen, muss ich eben auch beide auschecken. Das ist dann einmal mehr “git clone xxx” tippen.
Ich halte ein Projekt pro Repository für sinnvoll.
@Fancy Sicher. Ein vernünftiges Argument. Ich stimme auch vollkommen zu. Dass man nicht ein Repo names “MyStuff” mit 50 unverwandten Projekten drin haben sollte, ist klar.
Zwei Gegenargumente:
Das ganze funktioniert ja problemlos, wenn man dem ganzen eine künstliche Hierarchie überstülpt. Also in das Root-Verzeichnis des besagten “MyStuff”-Repos eine POM legen, die alle anderen POMs als Modules einbindet, und schon schluckt Maven diese Struktur (angeblich, hab’s nicht ausprobiert - wäre ja auch Murks). Hauptsache, eine POM liegt im Root-Verzeichnis. (Die Auswüchse, wenn man sich dazu genötigt sieht, und die Argumente a la ~“Das muss man so machen, weil anders geht’s nicht” kann man sich schon vorstellen)
EDIT>
1.5: Man kann sich Konstellationen vorstellen, wo so etwas Sinn machen könnte. Etwa eine Interface-Library und etliche Implementierungen, etwa irgendwelche Services oder so. Aber sei das mal außen vor gelassen.
<EDIT
VIEL wichtiger (und näher am konkreten Beispiel, über das ich jetzt so gekotzt habe) : Dass durch diesen (und jetzt nenne ich es mal so: ) Bug im Release-Plugin (!) auch Layouts wie
[quote=Marco13]2. VIEL wichtiger (und näher am konkreten Beispiel, über das ich jetzt so gekotzt habe) : Dass durch diesen (und jetzt nenne ich es mal so: ) Bug im Release-Plugin (!) auch Layouts wie
unmöglich werden, kann einfach nicht im Sinne des Erfinders sein[/quote]Ja aber warum dürfen die Ordner Samples\ Documentation\ und Screenshots\ nicht auf der selben ebene wie die POM liegen? oder anders, wieso dürfen die nicht Teil von “TheActualProject” sein?
Ich gebe dir ja Recht, dass das Release-Plugin buggy ist.
Aber andererseits verstehe ich auch Deinen Anwendungsfall nicht.
Eben, Tags sind Global im ganzen Repo in Git, warum man ueberhaupt mehrere Projekte in einem Repo haben will ist mir unverstaendlich, dann macht man halt Module draus oder splittet es gleich auf mehrere Repos.
Dass das Release Plugin Probleme hat ist bekannt (warum keine Branches fuer Tags etc. bis alles durchgelaufen ist? Aber man will ja auch noch CVS etc unterstuetzen… ), der Rollback funzt selten, allerdings liegt es in diesem Falle nicht am Release Plugin
Pro Projekt ein Repo, wenn sie alle in einem liegen, sind dass dann wirklich einzelne Projekte?
Ich habe auch gerade angestrengt nach Beispielen gesucht, wo ich 2 Projekte in ein Repo packen würde. Aber die beiden Projekte wären in allen Beispielen so eng verzahnt, dass es eigentlich sinnvoller wäre beide zu verschmelzen. Wenn sie so arg voneinander abhängig sind, dass eine Versionsverwaltung absoluter Overhead ist, dann gehören sie evtl. zusammen geschmissen in ein Projekt und somit ein Repo.
Natürlich „dürfen“ sie das. Sie sind aber nicht Bestandteil des Projektes im Sinne der Build-Infrastruktur. Sie gehören vielleicht konzeptuell und fachlich dazu, aber nicht technisch. Man könnte (d.h. sollte…können) das Projekt bauen, ohne den Screenshots-Ordner. Die Samples sind so gesehen der Grenzfall, wo das besonders deutlich wird: In der IDE hätte man (ich, z.B.) gerne zwei Projekte: Library und Samples. Das ist mit dem Release-Plugin offenbar nicht direkt vereinbar (d.h. nicht so, dass sich das auch in den Verzeichnissen widerspiegelt). Vermutlich müßte man für eine differenziertere Betrachtung wirklich unterscheiden, ob es nur um „Zusatzverzeichnisse“ wie Screenshots/Samples geht, oder um echte eigenständige Projekte (im Sinne des „Flat“ Layouts, wie es etwa in Maven-Multimodulprojekte sowie die Zusammenarbeit mit Eclipse und Mercurial beschrieben ist). Aber eigentlich ist es egal: Es funktioniert beides nicht. Für die Samples ein eigenes Repo ist overkill und IMHO unpraktisch. Bei „echt“ zusammengehörenden Projekten kann man wohl auf das Hierarchische Layout zurückgreifen. Aber die Anforderung „Die POM muss im Repo-root liegen“ ist technisch in keinster Weise gerechtfertigt, und dass das Release-Plugin das einfordert (und NUR dieses Plugin - alles andere funktioniert ja!), ist albern, und selbst WENN man das antizipiert, dann gibt es immernoch keine fundierte Rechtfertigung dafür, dass es blind irgendwelchen Mist zusammenpfuscht, anstatt schlicht eine Meldung auszugeben: „POM must be in repo root“ und abzubrechen, bevor es irgendwas kaputt macht.
[OT]Maven ist halt so wie Maven ist, da kann man fluchen soviel man will. Convention over Configuration.
[EVIL]Wenn einem das Release-Plugin nicht passt, dann kann man ja sein eigenes schreiben oder forken.[/EVIL]
Wie sieht es mit Gradle aus?
Vom Funktionsumfang sollte es mit Maven mithalten können.
Groovy-DSL anstatt XML ist jetzt auch kein Showstopper.
Es steht Groovy zur Verfügung um kleine Erweiterungen direkt unterzubringen, was mit XML allein etwas schwieriger ist.
Die Änderungen die @Timothy_Truckle mit einem Shellskript und du mit einer Batchdatei machen könntet, könnten direkt im Buildskript sein.
Andere Tools, andere Probleme gilt halt überall.
[/OT]
[ot]Fluchen und Lästern ist hier gar nicht sooo Off-Topic aber meinetwegen. Ich finde Maven an sich ja auch OK, und die Ideen, die dahinterstecken, sogar super (Verläßlichkeit, Dauerhaftigket, Provenance, und eigentlich sogar „Convention Over Configuration“). Aber für alles, was über die Gleichung „POM + JavaSourceFolder = Library“ hinausgeht, ist es eben ein Krampf, und dieses „Convention over Configuration“ wird dann nurnoch als hemdsärmelige Rechtfertigung dafür verwendet, dass bestimmte (wichtige, verbreitete, nahe liegende) Anwendungsfälle schlicht nicht abgedeckt sind. Dadurch, dass diese dann NUR durch absurd kompliziert-kryptische XML-Konfigurationen (sic!) abgedeckt werden können, oder man Maven selbst durch irgendwelche zusammengefrickelten Batch-Files ersetzen muss :sick: werden die oben genannten Ideen auf die groteskest-denkbare Weise ziemlich ad absurdum geführt.
(Davon, dass man in eine XML nur schlecht mal ein System.out.println("Now I'm doing this-and-that") reinschreiben kann, und das ganze dadurch schon zu einer seeeehr, sehr blacken Black-Box wird, mal abgesehen - solange alles funktioniert, stört das ja nicht )
Gradle hatte ich schon ein paarmal ins Auge gefasst, dass Gradle möglich ist, wäre schonmal ein wichtiger Punkt…
Wenn sie leichtgewichtig sind, würde ich sie als Test formulieren und unter src/test/java packen.
Edit:Als Beispiel, bei meinem net.nanojl:injector hab ich die typischen use cases als Test formuliert. Klick.
Vermutlich meinst Du aber Beispiele die Neulinge z.B. an die Verwendung einer Bibliothek heranführen sollen. Sobald das mehr in Richtung Tutorial geht, wurde ich das als ein eigenständiges Projekt in ein eigenständiges Repo packen. Neue Nutzer die das nutzen interessieren sich oft schlicht nicht für den Quelltext der Bibliothek und sollten den auch imho nicht auschecken müssen.
Ansonsten halte ich die POM für eine formalisierte Readme die alle wichtigen Infos enthält (Beschreibung, Projekt URL, Quellcode URL, Lizenz, Abhängigkeiten, Autor) und genau wie bei der Readme halte ich das Wurzelverzeichnis für den Platz wo die hingehört.
Hmja. So hatte ich es dann gemacht: Ein eigenes kleines Repo. Erscheint mir in diesem Fall schon unsinnig, aber … FALLS ich irgendwann doch mal eines meiner “größeren” Projekte veröffentlichen will, gibt das sicher einen Riesenspaß -_- Ich fände es eigentlich selbstverständlich, bestimmte Dinge in Module aufzuteilen, auch wenn sie zusammengehören. Und dass das alles dann daran scheitern soll, weil irgendein betriebsblinder Entwickler des Release-Plugins nicht auf die Idee gekommen ist, zu schauen, ob die Git-Wurzel vielleicht weiter oben liegt, ist albern. Und um dem “Das ist bei Maven eben so”/“Conventions over Configuration” hierbei zuvorzukommen: Ich würde nicht mal davon ausgehen, dass das “geplant” war. ALLES funktioniert, nur dieses eine Plugin nicht, und in den Bugreports dazu ist einges los. Ich würde sagen, dass da schlicht jemand geschlampt hat (relativiert dadurch, dass es sicher nicht trivial ist, CVS, HG, SVN, GIT & Co in so einem Plugin unter einen Hut zu bringen)
Wenn dass so ein Drecks-Maven ist, dann stellt sich mir die Frage: Warum benutzt Du es überhaupt?
Frage
Welche Maven Version?
Frage
Welche Version des maven-release-plugin verwendest Du?
[QUOTE=Marco13;125015]Das release:rollback hatte ich schon gesehen. Das ändert aber nichts an Tags und GitHub-commits. Ein dryRun bringt bei sowas halt auch keine Einsichten. Er listet nur auf, was er „machen würde“, aber nicht, dass das, was er da machen würde, nicht funktionieren würde. [/QUOTE]Hm…Maven ist ein Open Source Projekt…dann liefere doch entsprechende Patches wie man es besser macht ?
Weiterhin ist die Frage, wie ein Rollback über alle Versionskontrollsystem zu implementieren ist? Dann kommen wir zu solchen Sachen wie z.B. in Git git tag -d XYT (nur lokal und dann noch ein git push origin :tagName auch auf remote löschen) und selbstverständlich ein git push --force …(was kaum ein Git repo zu läßt mit recht…)…usw.
[QUOTE=Marco13;124988]
„Cool bleiben“ ist schwierig. Angenommen man hat ein Projekt, das aus mehreren Teilprojekten/Libraries besteht:
Und dieses (IMHO und aus meiner subjektiv-unfundierten Sicht einfache, gute, vernünftige, klare und nahe liegende(!)) Layout macht es unmöglich, eines dieser Projekte in die Maven Central zu bekommen?! Nur weil das Release-Plugin zu blöd ist, mal zu schauen: „Hey, bin ich überhaupt in einem Git-Repo-Verzeichnis?“ bevor es (nochmal: blind, ungeprüft und hartverdrahtet!) irgendwelche GIT-Kommandos ausführt? [/quote]
In Git kann man nun mal nur das Repository Taggen und nicht ein Unterverzeichnis wie in SVN …somit macht es auch sinn dann nicht so releasen zu können…über Fehlermeldung kann man sich gerne nochmal unterhalten…siehe mein Vorschlag von oben…Weiterhin wenn es ein Projekt mit Teilprojekten in Form von Libs ist dann ist dass eben ein Multi-Module projekt und man eine Parent POM wo die entsprechenden Module aufgeführt sind…Wenn es unabhängige Projekte sind, dann gehören die einfach nicht in ein Git Repo…
[QUOTE=Marco13;124988]
Dass das an sich ein Krampf ist, ist offensichtlich (link, link, link, link, so viele links, wie man will). Wenn man aber etliche der Lösungsvorschläge ausprobiert, und er jedesmal irgendwelchen Mist macht, und NIE irgendeine Fehlerbehandlung durchführt, sondern immer fleißig Tags und Commits erstellt, die man dann händisch zurücknehmen muss, dann nervt das einfach. [/quote]
Die links sind schlicht veraltet…zum Teil 5 Jahre…und Du scheint nicht mitbekommen zu haben, dass sich bei Maven als auch bein den Plugins eine Menge getan hat…Ja und definitv da sind Dinge die nicht so laufen wie Du sie gerne hättest…Aber ich kann Dich nur ermutigen eben Patches zu lieferen die das verbessern…
Ich kann da nur einen Blick auf das nar-maven-plugin empfehlen…ja durch aus ist die Frage, ob da Maven die richtige Wahl ist…
[QUOTE=Marco13;124988] Aber dass man mit Maven nichtmal zwei Projekte in ein Repository legen kann ist schlicht lächerlich. [/quote]Macht aus Git sicht keinen Sinn…macht bei SVN auch keinen Sinn wenn ich in einen trunk verschiedene Projekte legen wollte…würde da genauso nicht gehen und macht aus SVN/Git sicht eben keinen Sinn…
[QUOTE=Marco13;124988]Es gibt sicher eine Lösung. BAT-Dateien oder Shell-Scripte („Write once, run on one system (that hopefully is not a Mac)“), oder absurde Konfigurationseinträge in immer länger und undurchsichtiger werdenen POMs, die mit einer Version vielleicht funktionieren, und mit einer anderen vermutlich schon nicht mehr. [/quote]den letzten Teil verstehe ich nicht? „vermutlich schon nicht mehr“ schon praktische Beispiele wofür?
Dass man mit Maven ein Projekt nicht in ein Unterverzeichnis eines Repos legen kann, ist gut, weil … (?)
Siehe Git/SVN Ansatz…Der Release Zeitpunkt von zwei unabhängigen Projekten ist die Kernfrage…gleicher Release Zeitpunkt, dann wird daraus ein Multi Module Build somit geht das auch…wenn der Release Zeitpunkt unterschiedlich gehören die Projekte nicht in einzige Git Repository bzw. nicht unter den gleichen SVN-Trunk…
Dass man mit Maven nicht zwei zusammengehörende Projekte in einem Repo haben kann, ist gut, weil … (?)
Wenn die projeke zusammen gehören macht es sinn ein Multi-Module Projekt daraus zu machen…Wenn Sie eben nicht zusammen gehören dann eben unterschiedliche Projekte somit auch unterschiedliche Repositories (Git/SVN sicht). Nachvollziehbarkeit ist hier auch ein Stichwort…
Die Kernfrage scheint zu sein: pom.xml ins Root Verzeichnis? Ja/Nein/Warum?
Da kommt dann folgendes raus. Wenn jedes Projekt die pom.xml in ein unterzeichnis legen würde (selbstverständlich nicht überall gleich benannt sonst wäre dass ja auch eine Convention), dann müsste man bei jedem Projekt zuerst ein mal schauen wo denn die pom liegt…wenn man pom.xml direkt ins Root Verzeichnis legt braucht man darüber nicht nachzudenken… mvn clean package / mvn install …macht eben das Leben einfacher…
Das kann man auch verpacken etc. Dazu benötigt man aber eben ein pom.xml und zwar auf der obersten Eben…da kann man dann mithilfe von maven-assembly-plugin etc. auch Unterverzeichnisse (Samples/Documentation/Screenshots) mit verpacken…
Oder andere Möglichkeit das Ganze sieht ja nach Doku aus…in den Bereich der Site legen…
Kamas Vorschlag ist eine Möglichkeit, falls es sich um lauffähigen Quellcode handelt als Modul in das selbe Projekt, die Abhängigkeiten sind ja so stark dass es sich eben nicht um ein verschiedene Projekte handelt.
Auch wenn diese Art der Antworten/Unterhaltung selten zielführend ist…:
Das sollte weiter oben schon beantwortet worden sein. Maven „ist“ in diesem Fall das Plugin.
3.2.5
Verschiedene. Eigentlich das, was von Sonatype vorgegeben ist (2.1, AFAIK), aber in Links und Bugreports wurde dann gesagt: „Dies und das geht erst ab 2.2.1, aber auf keinen Fall 2.5, weil da geht es dann nicht mehr…“, … Funktioniert hat es mit keinem, aber natürlich habe ich nicht alle Möglichkeiten ausprobiert.
Die liegen hier in einer Textdatei, damit ich sie schnell in die Konsole Copy+Pasten kann. Vielleicht sollte ich mir da eine BAT dafür erstellen.
Er kann ja das Git repo taggen (d.h. das kann er nicht, zumindest nicht richtig). Was ich meine ist: Er dürfte (und sollte!) das auch. Aber irgendeines der Git-Kommandos, die er da so ungeprüft absetzt, ist eben falsch. Und worum es im konkreten Fall ging (Samples), im allgemeineren (Docs/Samples/Screenshots…), oder im allgemeiner-speziellen („Flat Project Structure“) sollte auch geklärt sein.
Nein. Selbst die Tools, die genau dafür gedacht sind, stoßen an ihre Grenzen, was Plattformspezifika angeht. Es gibt alternative Lösungen.
Diese Unterscheidung zwischen „Zwei Modulen“ und „Einem Multi-module-Projekt mit zwei Modulen“ ist doch Haarspalterei (und darum ging es ursprünglich ja auch gar nicht). Er braucht eine POM im root, sonst krachts. Darüber, ob ich das für sinnvoll halte, habe ich schon genug gesagt. Darüber, ob das ein Bug ist, könnte man streiten. (Will ich aber nicht).
Mit einer Version funktioniert irgendwas, und mit einer neueren Version nicht mehr.
Es ging eigentlich nie um Multi-Module-Projekte. Nur um ein Unterverzeichnis. Alles weitere hat sich aus der Diskussion und Fallunterscheidungen ergeben. (Aber ich verstehe das. DIESEN Beitrag wird sich auch kaum noch jemand durchlesen…)
Ja, sowas muss man dann wohl machen. Aber da Screenshots und Samples nicht integraler Bestandteil des Projektes an sich sind, widerstrebt mir das. Aber ob das nun die „richtige“ Lösung ist…
… oder nur eine von vielen Möglichkeiten, sich um praxisferne Konventionen herumzumogeln (und um etwas, wovon ich behaupten würde, dass es ein Bug im Release-Plugin ist), will ich nicht beuruteilen.
Das Verzeichnis, wo die POM drinliegt, ist das Projektverzeichnis, mit allem drum und dran. Auschecken, mvn install und gut. Dass das (ja: bescheuerte!) Maven aber, wenn jemand „mvn release:prepare“ an der Konsole eintippt (obwohl dieser jemand auch schon „„schlau genug““ war, den Pfad zur POM mit anzugeben, und andere Sachen zu machen, die man im Netz zu diesem Thema findet), meint, kackfrech blind und ungeprüft (!) durch das Ausführen irgendwelcher hartverdrahteter Befehle (!) im SCM rumpfuschen zu müssen, ist einfach schlecht - RICHTIG schlecht. Nachdem ich ca. 10 mal das Tag, das er natürlich fleißig erstellt, wieder gelöscht habe, und 10 mal das „-SNAPSHOT“ wieder zur Versionsnummer hinzugefügt habe, und ca. 10 mal mit „reset – hard / push -f“ den Mist, den er im SCM macht, wieder rückgängig gemacht habe, bin ich einfach angefressen. Die Argumentation von „convention over configuration“ erscheint dabei ungefähr so sinnig, wie zu sagen, dass eine .BAT-Datei mit der Zeile „javac MyProgram.java“ ein universelles Build-System ist, solange jeder sich an die „convention“ hält, sein Programm „MyProgram.java“ zu nennen. Polemisch? Ja. Ungerechtfertigt? Nun, ich bin offen für Argumente, warum es unmöglich sein soll, ein Projekt in ein Unterverzeichnis zu packen.
), der Rollback funzt selten, allerdings liegt es in diesem Falle nicht am Release Plugin 
aber meinetwegen. Ich finde Maven an sich ja auch OK, und die Ideen, die dahinterstecken, sogar super (Verläßlichkeit, Dauerhaftigket, Provenance, und eigentlich sogar „Convention Over Configuration“). Aber für alles, was über die Gleichung „POM + JavaSourceFolder = Library“ hinausgeht, ist es eben ein Krampf, und dieses „Convention over Configuration“ wird dann nurnoch als hemdsärmelige Rechtfertigung dafür verwendet, dass bestimmte (wichtige, verbreitete, nahe liegende) Anwendungsfälle schlicht nicht abgedeckt sind. Dadurch, dass diese dann NUR durch absurd kompliziert-kryptische XML-Konfigurationen (sic!) abgedeckt werden können, oder man Maven selbst durch irgendwelche zusammengefrickelten Batch-Files ersetzen muss :sick: werden die oben genannten Ideen auf die groteskest-denkbare Weise ziemlich ad absurdum geführt.
)