Ich bin gerade dabei eine "Organization pom" ("Firma-Super-Pom") zu basteln. Da habe ich einige Fragen zu:
Wie bindet man die am besten ein - als "parent pom" oder geht es auch irgendwie globaler über die settings.xml (gute Idee?)?
Zu einigen Teilen der pom gibt es ja "management"-tags (z.B. pluginManagement, dependencyManagement..) wofür gibt s das bzw. sind das die tags speziell für "parent"-poms (benötigen selbst kein plugin aber wollen was darüber sagen)?
Was diese management-Tags betrifft: gibt es sowas für Versionskontrolle? Bei uns gibts einen svn-server und damit sehen alle scm Pfade sehr ähnlich aus: svn://firmenSvn/ProjektName\trunk (...tags). Kann man das auch irgendwie global festlegen? Sodass lokal nur noch der "ProjektName" festgelegt wird und vielleicht per Default "<artifactId>" benutzt wird?
Ansonsten hab ich vor diese Firmen-Pom wie ein Projekt mit eigenem SVN und Releasezyklus zu behandeln - ok?
Gibt es noch Tips/Best Practices zur Verwendung von solchen Globalen Poms? Was sollte rein was auf keinen Fall?
Zu einigen Teilen der pom gibt es ja "management"-tags (z.B. pluginManagement, dependencyManagement..) wofür gibt s das bzw. sind das die tags speziell für "parent"-poms (benötigen selbst kein plugin aber wollen was darüber sagen)?
pluginManagment definiert die Versionen von Plugins damit in den abgeleiteten POM nur noch der Name der Plugins definiert werden muss bzw. darf und somit immer von der Parent-Pom bestimmt welche Version des Plugins verwendung findet. Etwas das gleiche macht dependencyManagement..für dependencies.
Was diese management-Tags betrifft: gibt es sowas für Versionskontrolle? Bei uns gibts einen svn-server und damit sehen alle scm Pfade sehr ähnlich aus: svn://firmenSvn/ProjektName\trunk (...tags). Kann man das auch irgendwie global festlegen? Sodass lokal nur noch der "ProjektName" festgelegt wird und vielleicht per Default "<artifactId>" benutzt wird?
Nein kann man nicht, da diese Pfade beim Release ersetzt werden und somit eine Festlegung in Form einer Property etc. keinen sinn machen...in Multi-Module build macht die definition nur in der Parent POM sinn...
Ich habe gerade gestern Maven 3 installiert. Das heißt "mixins" sind nicht relevant für mich?
Was passiert eigentlich wenn jemand lokal eine andere Version verwendet (das version-tag setzt)? Wenn ich es richtig verstanden habe setzt man Versionen für Plugins und Abhängigkeitet per "management-tags". (default)Einstellungen für Erben setzt man in den "normalen" tags, oder?
Zum drüberschauen und kritisieren hier mal meine UrMutter-pom:
Leider werden die properties nicht vererbt. Da wäre wahrscheinlich ein Weg über ein entsprechenden archetype zur Erzeugung der default struktur besser....
Die Properties in der POM machen keinen sinn, da die versionsnummern ja nur im pluginManagement bzw. dependencyManagement Abschnitt Verwendung finden.
Das Compiler Plugin würde ich nur in den pluginManagement bereich packen aber nicht in den Build bereich, da sonst jede POM die davon erbt direkt einen Build ausführt...das gibt manchmal etwas komische Effekte...Wichtig ist die Konfiguration für das Compiler Plugin kann trotzdem im pluginManagement Bereich abgelegt werden.
ich würde auch raten als Properties nie sowas [c]xxx.version[/c] zu nehmen. Da gab es afaik auf der Mailingliste nen Thread da das .version zu komischen Fehlern führte
die Versionen per Property festzulegen und xxx.version zu nennen hab ich aus irgendeinem google-Fund zu diesem Thema. Also die einzigen Sachen die ich mit der Orga-Pom anstellen will, sind im Moment die Java-Version(1.6), das Encodeing(utf-8), das distribution-management und der ganze Headerkram.
Geht das alles? Wenn ja wie bzw. was muss ich an meiner pom ändern?
Du solltest die Java Version (Compiler) plugin in den pluginManagement Bereich packen und dort auch die Konfiguration für das Plugin angeben...
Das Problem mit dem Encoding ist, dass die Properties nicht vererbt werden...somit wäre es zu überlegen die üblichen Verdächtigen im pluginManagement anzugeben und auch für das Encoding zu konfigurieren...(z.B. resources plugin etc.).
ist das in meinem Sinne? - falls irgendein anderes Plugin eine encoding Einstellung hat mach ich es analog zum Compliler-Plugin?!
Was sollte eurer Meinung eventuell noch in diese pom?
ich hab mal doch noch eine Frage zu den Properties: Falls ich diese in der Mutterpom setze und gleichzeitig verwende (z.b. im Plugin-Management), dann wird ihr Wert zumindest indirekt vererbt, oder?
Also ich würde Encoding und Versionen per Property setzen (dan sieht man de"wichtigen" Werte alle zusammen in der Orga pom) und dann in der Orga-Pom direkt verwenden - bei "encoding" oder "version". So müsste es funktionieren oder?
Falls das funktioniert wie sieht es mit default-Werten aus: In der Orga pom habe ich: "<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>"
des weiteren habe ich im Plugin-Management einige Plugins, deren Encoding per default auf "${project.build.sourceEncoding}" gesetzt wird - interessiert das irgendwie die Kindprojekte? Also falls das Kindprojekt das Encoding nicht explizit setzt welches Encoding benutzt dann das Kind?
Alternativ würde ich in allen Plugins die "Encoding" benutzen, dies explizit setzen:
<encoding>${project.build.sourceEncoding}</encoding>
das würde dann in der Mutter pom durch die lokale Propertiy ersetzt und die Kinder würden es erben oder?
(Um das mal selbts prüfen zu können: kann ich irendwie effektiv wirksame Einstellungen abfragen?)
Ja, musst halt daran denken auch die Parent oder besser "Company Pom" zu bauen & installieren/deployen.
Wobei ich niemals das encoding als Propepty definiteren & vererben würden ,oder kennst du einen Anwendungsfall für den utf-8 nicht geeignet ist?
Die Javaversion für den Compiler dagegen kann man auchmmal auf 1.5 oder gar 1.4 setzen wenn man es zB. mit legacy Projekten zu tun hat, mit anderen Worten würde es imho Sinn machen eine Company Pom pro verwendeter Javaversion zur Verfügung zu stellen, dann noch eine für WebApps, etc. pp., natürlich alle mit entsprechender Reporting Konfiguration für Unittests & Code Coverage, Repo aktivität (zB. mit svnstat) Code MEtriken (FindBugs, CPD, usw.).
das die Company-pom irgendwann mehr kann als mein erster Versuch ist das erklärte Ziel. Im Moment soll nur der allerkleinste gemeinsame Nenner gefunden werden: Java 1.6 und UTF-8. (Legacy-Projekt sollen nicht nach Maven megriert werden).
Was meinst du damit ",oder kennst du einen Anwendungsfall für den utf-8 nicht geeignet ist?" - heißt das, dass utf-8 der Standard ist? Also wenn man utf-8 wünscht man gar nix machen muss?
SVN unterstützt utf-8 per default,, damit gibt es keine Probleme, Eclipse nimmt unter Linux utf-8 und unter Windows per default ein Windowsspezifisches welches mir gerade nicht mehr einfällt (arbeite nur noch mit utf-8 ), wenn das Kompilerplugin richtig konfiguriert ist, sollte das m2eclipse Plugin die Einstellungen auch übernehmen (konkret utf-8 für Eclipse unter Windows etc.).
Kurz: utf-8 für alles und gut ist, kein Bedarf für ein anderes Encoding.
das mit windows ist ja mein Problem: unter Windows wird nicht UTF-8 genommen. Ich will aber immer UTF-8. In Eclipse hab ich das schon workbenchweit eingestellt. Aber mein Verdacht war eben, dass Maven genau wie Eclipse das System-Encoding als default nimmt und das will ich unterbinden.
