Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich hab eine größeres GWT-Maven-Eclipse Projekt inklusive einiger Unit-Tests. wobei die Unit Tests wirklich nur "Units" testen und völlig umgebungsunabhängig laufen - wie es eben sein sollte.
(eine Jenkins-Instanz läuft bereits und führt die Unit-Tests aus)
Das macht nun eben Integrationstests umso wichtiger. Mein Ziel wäre ein vom Hauptprojekt möglichst unabhängiges Projekt für Integrationstests aufzusetzen, welches nur Code im Test-Zweig hat. Dieses Projekt würde dann als "Downstream"-Projekt nach dem Hauptprojekt von Jenkins getestet werden.
Folgende Probleme hab ich nun:
Ich würde das Hauptprojekt sehr gerne unberührt lassen ("parent" auch - im Moment eine allgemeine "corporate"-pom) - diese Position wäre verhandelbar ;-)
Andererseits soll das Testprojekt automatisch immer vom aktuellsten Hauptprojekt abhängig sein - analog wie bei einem Multi-Module-Projekt (optimal wäre wenn "mvn test" erst das Hauptprojekt und dann das Testprojekt baut).
Fragen:
- Geht das? und wie?
- Welche Alternativen gäbe es?
Im Moment hab ich folgenden Stand:
Ich habe ein Mutterprojet was beide Projekte als Module führt. Da aber das Hauptprojekt eine andere Mutter hat spuckt Maven (gerechtfertigter Weise) eine Warnung aus.
Im Moment ist auch eine Feste Version des Hauptprojekts als Abhängigkeit im test-projekt eingetragen - ist auch blöd.
(ich bin bereit das völlig zu revidieren - bei minimaler Änderung am Hauptprojekt)
So mach ich das meistens:
Integrationstests in ein eigenes Modul, falls die ITests nicht immer ausgeführt werden sollen, wird dieses Modul eben nur von einem bestimmten Profil eingebunden, der CI Server aktiviert dieses Profil natürlich und führt dadurch die tests aus.
das heißt es gibt ein "multi-module-projekt" welches im standardprofil nur ein Modul hat und im ci-profil 2 module?
Die nächste Frage wäre: müssen beide Module diese multi-module-projekt als Mutter haben (kann man das parent segment ach per profil ändern?)? (Maven: The Complete Reference / Documentation Sonatype.com suggeriert, dass es nicht sein muss - aber mich nervt die Warnung)
hättest eventuell die Zeit Beispiel-pom-ausschnitte zu posten?
ICh bin mir auch unsicher wie das mit den Versionen funktioniert - im Moment gibt das HAuptprjet die Version vor. Wie teile ich die Version "allen" mit? (theoretisch muss das multimodule-projekt ja nix von der version wissen)
Edit:
ich glaub nun hab ichs richtig verstanden: Das Hauptprojekt selbst bekommt ein oder 0 Module je nach Profil. Und das IT-Projekt ist dann per DependenyManagement abhängig vom <Hauptprojekt> und version "${project.version}" -- oder?
Wie schon vorgeschlagen, kann man den Eintrag mod-it mithilfe eines Profiles steuern ...das bedeutet, dass die Möglichkeit besteht, dass per Profil der Integrationstest ausgeführt werden können.
Ich bevorzuge aber als Modul OHNE Profil damit wird per:
Code:
mvn clean package
nur unit-tests etc. und per
Code:
mvn clean verifiy
auch die Integrationstests ...
(Nachteil, damit wird man auch gezwungen das im Falle einer Release (mvn release..) laufen zu lassen...).
Danke KAMA, aber die Separation bei "in Module"-Integrationstests ist mir nicht stark genug. Bzw. hätte das nun zu viel Einfluss auf das Projekt.
Ich werde deshalb zunächst makis-Vorschlag folgen (mal sehen ob ichs richtig verstanden habe):
- Mein Hauptprojekt bekommt im ci-profile ein Modul
Damit fühlt sich das Hauptprojekt an wie immer (für die Entwickler die nix mit IT am Hut haben) - bis auf den zusätzlichen Ordner. Das könnte man noch umgehen in dem man IntegrationsTests eine Ebene höher packt - mal sehn.
DasIT-Projekt bekommt dann einfach einen entsprechenden parent-Eintrag und eine Abhängigkeit:
Code:
<dependency>
<artifactId>Hauptprojekt</artifactId>
</dependency>
[CODE]
Das sollte es ssein oder? - Die Versionen (der Abhängigkeit, des IT-Projekts und dessen Parent sollten sich dann automatisch anpassen oder???)
mhm so wie ich es verstanden hab funtkioniert es leider nicht:
Das parent-pom von Testmodul kann ja nicht das Hauptprojekt sein, da es "war" ist und nicht "pom". Andererseits falls ich mir ein parent baue, welches die Module einbindet, dann wäre meine Idee dieses parent-Projekt nur auf dem CI zu bauen.
Der Standardentwickler würde dann immer nur das Hauptprojekt direkt bauen - einen Schalter für Module bräuchte man dann nicht, oder?
das wäre der klassische "multi-module-iTest-Ansatz" oder?
Ich mache damit gerade Experimente. Meine Sorge betrifft die Arbeitszyklen, welche sich für die normalen Entwickler möglichst nicht ändern sollten:
-Ist es möglich, dass die Entwickler nur das war-modul ausschecken und nix vom parent mitbekommen? Dafür könnte/müsste man parent und module auf die selbe ebene hiefen?!
- Ein release müsste man dann immer mit dem parent machen oder? (wäre kein Problem)
- Der ci Server würde einfach immer das parent bauen oder?
(nichts desto trotz würde mich makis Ansatz interessieren, denn dieses Module schalten per Profil kam mir vor einiger Zeit auch in den sinn ich hab es aber nie ausprobiert.)
hier noch wie weit mein Experiment gerade ist - mit Problem:
parent.pom:
Danke kama,
das wäre der klassische "multi-module-iTest-Ansatz" oder?
Ich mache damit gerade Experimente. Meine Sorge betrifft die Arbeitszyklen, welche sich für die normalen Entwickler möglichst nicht ändern sollten:
Was soll das denn...Der Entwickler checkt den Baum aus und Arbeitet mit Eclipse/Netbeans/IntelliJ oder sonst was und beachtet das -it Module nicht...?
Du kannst natürlich auch das integrations-test module parallel auf gleicher Ebene machen...finde ich aber, dass das nicht die eigentliche Struktur des Projektes wiederspiegelt...ist aber geschmacksache...
-Ist es möglich, dass die Entwickler nur das war-modul ausschecken und nix vom parent mitbekommen? Dafür könnte/müsste man parent und module auf die selbe ebene hiefen?!
Das ist möglich. Der Haken ist nur, dass dann der Rest des Projektes immer per mvn deploy entsprechend zur Verfügung steht, damit der Entwickler arbeiten kann....
Das Problem liegt in der dependency -> einfach weg...und wenn schon dann auch bitte die Version per ${project.version} (abgesehen davon dass es da nichts zu suchen hat!).
Vielen Dank!
(insbesondere für den Hinweis mit dem DependencyManagement - ist nun raus)
"Das ist möglich. Der Haken ist nur, dass dann der Rest des Projektes immer per mvn deploy entsprechend zur Verfügung steht, damit der Entwickler arbeiten kann...."
in meinem Fall wäre das ja nur der aktuelle Snapshot des parent oder? Könnte man das umgehen in dem die "project.version von einem Modul gesetzt wird? Das parent ändert sich ja nie?
Bzw. eigentlich will ich ja "nur", dass der Test immer von der aktuellen Version des Hauptprojekts abhängt. Prinzipiell könnten es auch völlig unabhängige Projekt sein.
Wodurch wird eigentlich project.version gesetzt? durch die parent-beziehung oder durch die modul-beziehung?
(ich will die "Konventionen" aber nicht zu sehr verbiegen zur Not wird eben nach jedem Release der Snapshot von parent deployed oder die Entwickler checken eben alles aus und müssen immermal nen update auf dem parent machen)
- das problem sind nicht die Entwickler die ich raushalten will, sondern die Fragilität der Konfiguration: gwt-eclipse(3.6)-maven ist kein besonders harmonisches Gespann - damit es bei jedem läuft muss man immer etwas rumschrauben. (mit eclipse 3.7 läuft es noch gar nicht - zumindest nicht ohne Anpassung der pom und oder der .project-Konfiguration)
Meine Sorge ist, dass eine zu große Änderung in der Projektkonfiguration Stress verursacht. (Ja man hätte das Testprojekt gleich am Anfang dabei haben sollen :-|)
in meinem Fall wäre das ja nur der aktuelle Snapshot des parent oder? Könnte man das umgehen in dem die "project.version von einem Modul gesetzt wird? Das parent ändert sich ja nie?
Warts ab..das wird sich ändern...vor allem wenn Du dort dependencyManagement Bereich und pluiginManagement Bereich eingebracht hast um die Konfiguration der Plugins und die Dependencies zu vereinheitlichen...
Bzw. eigentlich will ich ja "nur", dass der Test immer von der aktuellen Version des Hauptprojekts abhängt. Prinzipiell könnten es auch völlig unabhängige Projekt sein.
(ich will die "Konventionen" aber nicht zu sehr verbiegen zur Not wird eben nach jedem Release der Snapshot von parent deployed oder die Entwickler checken eben alles aus und müssen immermal nen update auf dem parent machen)
- das problem sind nicht die Entwickler die ich raushalten will, sondern die Fragilität der Konfiguration: gwt-eclipse(3.6)-maven ist kein besonders harmonisches Gespann - damit es bei jedem läuft muss man immer etwas rumschrauben. (mit eclipse 3.7 läuft es noch gar nicht - zumindest nicht ohne Anpassung der pom und oder der .project-Konfiguration)
Meine Sorge ist, dass eine zu große Änderung in der Projektkonfiguration Stress verursacht. (Ja man hätte das Testprojekt gleich am Anfang dabei haben sollen :-|)
"Das schreit förmlich nach einer parent pom mit dependencyManagement und pluginManagement"
so eine habe ich (zumindest eine allgemeine für alle Projekte - "corporate pom") und die ist im Moment parent.
Nun würde ich das parent mit den 2 Modulen dazwischen schalten.
Ich hab nebenher auch noch etwas rumüberlegt, aber du hast völlig recht: Um ein parent mit den 2 Modulen und der Notwendigkeit das dies lokal nötig ist (Entwickler müssen das ausschekcen und update darauf machen) werde ich nicht drumrum kommen.
(Ich sehe mich nun wieder nochmehr zu den Entwicklern rennen um ihnen clean, update (nun auf dem Hauptprojekt), ... usw auszuführen da es mal wieder Probleme gibt - insbesondere hakt es immer wieder an der Synchronität zwischen Maven und Eclipse - m2eclipse scheint sein möglichstes zu tun)
so eine habe ich (zumindest eine allgemeine für alle Projekte - "corporate pom") und die ist im Moment parent.
Nun würde ich das parent mit den 2 Modulen dazwischen schalten.
Ja...das hatte ich vermutet....
Also die "coperate"-POM ist selbstverständlich ein eigenes Projekt und wird auch getrennt released..
Der Parent für Dein Projekt ist eine andere Sache...
Ich hab nebenher auch noch etwas rumüberlegt, aber du hast völlig recht: Um ein parent mit den 2 Modulen und der Notwendigkeit das dies lokal nötig ist (Entwickler müssen das ausschekcen und update darauf machen) werde ich nicht drumrum kommen.
(Ich sehe mich nun wieder nochmehr zu den Entwicklern rennen um ihnen clean, update (nun auf dem Hauptprojekt), ... usw auszuführen da es mal wieder Probleme gibt - insbesondere hakt es immer wieder an der Synchronität zwischen Maven und Eclipse - m2eclipse scheint sein möglichstes zu tun)
Ich habe hier Maven vor ca. 1,5 Jahren erst eingeführt und die leider mangelnde Zusammenarbeit zwischen Eclipse (3.6 mit m2eclipse) und Maven haben die Sache nicht einfacher gemacht. Ich selbst blicke nach wie vor nicht völlig durch wann man "clean" oder "package" oder "project clean" machen mussen um Eclipse synchron zu halten (wenn irgendwas nicht stimmt wird es halt gemacht).
Mir ist bewusst, dass m2e diese Probleme grundsätzlich löst (bzw. war es das Ziel), aber solange gwt damit noch mehr Schwierigkeiten* hat als mit m2eclipse werden wir wohl nicht umsatteln.
*Unser Projekt läuft so wie es ist nicht in Indigo bzw. nicht mit m2e. Dafür wären wohl einig Anpassungen in der pom nötig (Wieso soll ich die pom für eine IDE anpassen?) - ich versuchs aller paar Monate wieder ob sich diesbezüglich etwas getant hat
Lange Rede kurzer Sinn: Danke kama, Danke maki. - meine nächste Frage kommt betimmt ;-)
"Das ist möglich. Der Haken ist nur, dass dann der Rest des Projektes immer per mvn deploy entsprechend zur Verfügung steht, damit der Entwickler arbeiten kann...."
Falls ein Modul nicht direkt unter dem parent ist sondern auf der selben Ebene
Code:
<module>../einModul</module>
kommt man um das deployen des parents - nach jedem release - nicht herum oder? - maven findet das parent sonst nicht oder?
im module keine ".." eintragen...sondern in der Pom kann man im parent per "relativePath" ...entsprechende Eintragungen machen, damit man den Parent bekommt...falls der nicht unter "../pom.xml" zu finden ist...
mich haben schon die komischen Warnungen in Jenkins gestört - die meinten irgendwas mir relatve Path.
Ich hab mal noch eine Frage zu Jenkins:
Dort brauche ich ja nur das parent eintragen als Job?! Nur hab ich da ein Problem: wenn ich "archive the artifacts" anmache - wie komme ich vom parent nach ../hauptPr/target/*war - "../" scheint da nicht zu funktionieren?! - man kann anscheinend nur dinge innerhalb des aktuellen ordners archivieren?!
Inwiefern ist eigentlich mein Einwand relevant, das falls man ein Modul außerhalb vom parent packt man nach jedem Release den Snapshot deployen muss?
oder löst das genau die Angabe des relativen Pfades bei parent?
Oder anders gefragt lohnt es sich die Struktur im SVN zu ändern, so dass sie den Konventionen (alle module unter parent) entspricht?
EDIT
ohne "<module>../einModul</module>" scheint es nicht zu funktionieren:"Child module ... does not exist"
Nur hab ich da ein Problem: wenn ich "archive the artifacts" anmache - wie komme ich vom parent nach ../hauptPr/target/*war - "../" scheint da nicht zu funktionieren?! - man kann anscheinend nur dinge innerhalb des aktuellen ordners archivieren?!
Wenn Du Dein Projekt baust...werden ja alle Artefakte von Maven im target folder erzeugt und dass kannst Du bei der Auswahl für "Archive artifact" mit dem Muster bestimmer was denn archiviert werden soll....
"Wenn Du Dein Projekt baust...werden ja alle Artefakte von Maven im target folder erzeugt und dass kannst Du bei der Auswahl für "Archive artifact" mit dem Muster bestimmer was denn archiviert werden soll...."
Das Problem ist, dass das parent-pom keine "target" hat und somit kann nix archiviert werden - ist kein Problem nur hat mich der Fehler zunächst verwundert.
Mit dem deployen meinte ich:
Sobald durch das release das Modul was außerhalb des Ordners liegt eine neue Version des parent benötigt (die wird ja durch das release-plugin auch hochgesetzt oder?), frage ich mich ob dieses modul das aktuelle parent findet.
inzwischen denke ich "ja" - denn das wird durch relativePath sichergestellt- oder?
ich hab die struktur nun nicht geändert und einfach das hauptmodul und das parent nach jenkins geholt. die upstream/downstream-relation scheint jenkins selbst zu erkennen: er baut erst parent und dann das modul. (später werd ich dann noch da it-modul reinholen)
was ich mich da noch frage ist wie man in so einem fall metriken bekommen kann, denn das it-modul deckt ja code des anderen moduls ab - kann man das messen?
Oder allgemein gesagt ich ab keine ahnung wie man so ein modul--it-modul--parent-modul --Projekt vernünftig in jenkins abbildet.
"Wenn Du Dein Projekt baust...werden ja alle Artefakte von Maven im target folder erzeugt und dass kannst Du bei der Auswahl für "Archive artifact" mit dem Muster bestimmer was denn archiviert werden soll...."
Das Problem ist, dass das parent-pom keine "target" hat und somit kann nix archiviert werden - ist kein Problem nur hat mich der Fehler zunächst verwundert.
Die Frage ist warum Du mit Jenkins archivieren möchtest?
Du kannst ja per jenkins bauen (mvn deploy) und mit dem Deploy werden die SNAPSHOT Versionen im Repository Manager abgelegt (Nexus, Artifactory, Archiva ..)...und stehen dann für alle zur Verfügung...
Jenkins kann auch einen Release build machen und dabei werden dann die Versionen entsprechend geändert aus z.B. 1.2.0-SNAPSHOT wird dann 1.2.0 und die nächste Entwicklungsversion ist dann 1.2.1-SNAPSHOT....(kann man per Optionen beeinflussen..)...
Mit dem deployen meinte ich:
Sobald durch das release das Modul was außerhalb des Ordners liegt eine neue Version des parent benötigt (die wird ja durch das release-plugin auch hochgesetzt oder?), frage ich mich ob dieses modul das aktuelle parent findet.
inzwischen denke ich "ja" - denn das wird durch relativePath sichergestellt- oder?
Dann wird auch im Release Falle auf der Ebene "DeinProjekt" ein mvn releaserepare releaseerform durchgeführt...Durch die Verknüpfungen (parent / modules) werden alle Module entsprechend gebaut und auch später deployed (Repo Manager)...
was ich mich da noch frage ist wie man in so einem fall metriken bekommen kann, denn das it-modul deckt ja code des anderen moduls ab - kann man das messen?
Oder allgemein gesagt ich ab keine ahnung wie man so ein modul--it-modul--parent-modul --Projekt vernünftig in jenkins abbildet.
Du kannst dir dass ja mal hier anschauen für den Anfang....Wenn Du Fragen hast gerne ...
Was verstehst Du unter Metriken ? Code Coverage oder einen Report über erfolg/miserfolg der Integrations-Tests ?
Code-Coverage für Integrations-Tests ist nicht ganz so einfach...geht aber...Reporting der Integrations-Tests dafür gibt es das maven-failsafe-plugin (zur Durchführung / Reporting)...
(So ich bin aus dem Urlaub zurück - Wer noch? Ein frohes Neues an alle)
"Die Frage ist warum Du mit Jenkins archivieren möchtest?"
Du hast wahrscheinlich völlig recht. Das einzige was ich archivieren möchte sind die Ergebnisse und Metriken und nicht die Artefakte.
Wobei beim "Parent" da auch nicht viel zu holen ist?! Prinzipiell frage ich mich eben wie Jenkins das parent "misst" - werden in ihm einfach alle Module summiert? Oder sind alle Metriken "0"/nicht verfügbar, da ja kein Quellcode drin ist?
(Mir geht es hauptsächlich um Emma-Coverage, aber Sonar (ein ***** voll Metriken) würde ich auch gern mal testen)
Insgesamt frage ich mich wie man Jenkins für ein Multimodule-Maven-Projekt konfiguriert bei dem ein Modul Integrationstests sind.
- jedes Modul und Parent in Jenkins einrichten?
- wie welche Plugins und mvn targets konfigurieren pro modul?
Was die Projektkonfiguration betrifft: die ist eben nicht ganz standardkonform sondern so:
Hauptprojekt
-- pom (parent: ../Parentprojekt/pom.xml)
Parentprojekt
-- pom (module: it-projekt, ../Hauptprojekt; parent:corporate-pom)
-- it-projekt
-- pom (parent: Parentprojekt)
In Jenkins wird dann einfach das Hauptprojekt per mvn ausgeführt....auf keinen Fall jedes Modul in Jenkins einrichten...
Bei einem Integrationstest wird einfach das Hauptprojekt per mvn clean verify ausgeführt (was die IT einschliesst)...Hier ist ein Beispiel eines maven-plugins (http://78.46.16.202:8080/jenkins/job/appassembler-plugin/)..dabei werden die Integrations-Tests per Profil aktiviert...
in meinem speziellen Fall interessieren mich ja die Metriken vom Hauptprojekt, deshalb hab ich dieses Modul separat drinne - funktioniert auch einwandfrei (Jenkins sieht die Abhängigkeiten und baut es bevor er das parent baut).
Das it-projekt besteht im moment nur aus "/test/java" und benutzt auch das surefire-plugin (mvn package führ jenkins aus).
Braucht man da überhaupt "verify"? Also im Moment werden parent, hauptprojekt und it-modul einfach mit mvn clean package gebaut.
Im Moment sehe ich dadurch die "Summe" der Testresultate im parent und die einzelnen Ergebnisse eben in den Teilmodulen. Weitere Metriken interessieren mich eigentlich nur für das Hauptprojekt wobei ich bei der Coverage gerne den Beitrag der it-Tests sehen würde (ich bin mir bewusst das 50% + 50% keine 100% - alles ist super ergeben ;-)).
Auf den ersten Blick hat nur das 3. deiner Beispiele die it in einem extra modul (SupoSE, supose-it)? Bis auf die Resultate gibts danicht viel zu sehen?
Es verwendet failsafe anstatt surefire - warum?
das Maven-Failsafe-Plugin ist eben für die Ausführung von Integrationstests gedacht und nicht das surefire...Bei einem Integrationstest heißen die Dateien "xyzIT.java" etc. bei surefire (für Unit Tests) eben "xyzTest.java" ...
Weiterhin gibt mir das die Möglichkeit die Integrationstest Resultat auch per maven in einem Projekt Report einzubauen......auch innerhalb eines einzigen Moduls...
In dem Falle wo der IT ein getrenntes Modul ist ist das nicht so kritisch...ich würde es trotzdem so machen...
Dass die Integrationstest auch bei mvn package ausgeführt werden ist eben ein Hinweis darauf dass Du es nicht ganz "sauber" machst...
Im Build-Life-Cycle liegen nun mal die Integrationstest nach der Package Phase...
Code:
compile ...
unit tests
package
integration tests
install
deploy...
Das ist auch der Grund warum ich die Nutzung mit dem failsafe-plugin vorziehe...
Jetzt mal abgesehen von der oben aufgeführten Problematik gibt es nun mal einen Unterschied zwischen Unit Tests und Integrationstests....
Ok, dann werde ich im it-Modul das Failsafe-Plugin verwenden. Muss ich nun alle Tests mit IT benennen? (Wahrscheinlich kann man diese Konvention auch ändern?)
Nun fehlt mir nur noch eins - Wie macht man praktisch Integrationstests (oder Tests noch höherer ebenen) insbesondere für (GWT)Webanwendungen (Server, DB-Umgebungen starten und beenden, nimmt man Junit oder TestNG).
Ok, dann werde ich im it-Modul das Failsafe-Plugin verwenden. Muss ich nun alle Tests mit IT benennen? (Wahrscheinlich kann man diese Konvention auch ändern?)
Nun fehlt mir nur noch eins - Wie macht man praktisch Integrationstests (oder Tests noch höherer ebenen) insbesondere für (GWT)Webanwendungen (Server, DB-Umgebungen starten und beenden, nimmt man Junit oder TestNG).
Meiner Erfahrung nach TestNG weil es eben gerade im Bereich der Integrationstest (ich mache damit Selenium Tests auch für eine Web-Anwendung)...einiges bietet...was JUnit nicht bietet...
Übrigens ich werde nun doch die Projektstruktur umbauen so dass beide Module unter parent sind. Denn ich bin darüber gestolpert: subversion: Issue 2381
svn (bis 1.6) kommt nicht damit klar 2 Ordner (in meinem Fall Hauptprojekt und parent) aus einem nicht svn-ordner (working copy) auszuchecken/upzudaten (was auch immer mvn releaserepare macht).
Update auf 1.7 war keine Alternative.
repare ...)..
