# [Maven] Separates Integr.Test Projekt/(Modul) hinterher "anfügen"



## dermoritz (20. Dez 2011)

Folgendes Scenario:

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)

Vielen Dank im Voraus


----------



## maki (20. Dez 2011)

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.


----------



## dermoritz (20. Dez 2011)

Danke für die schnelle Antwort

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?


----------



## kama (20. Dez 2011)

Hi,

ein solches Multi-Modul Projekt mit Integrations Tests kannst Du Dir hier anschauen (Erkärungen):

Container Integration Test Example

und mit allen POM's etc: hier:
https://github.com/khmarbaise/maui/tree/master/src/main/resources/it-example-container

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:


```
mvn clean package
```
nur unit-tests etc. und per 


```
mvn clean verifiy
```
auch die Integrationstests ...
(Nachteil, damit wird man auch gezwungen das im Falle einer Release (mvn release..) laufen zu lassen...).

Gruß
Karl Heinz Marbaise


----------



## dermoritz (20. Dez 2011)

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

```
<profile>
			<id>ci</id>
			<modules>
			 <module>IntegrationsTests</module> 
			</modules>
			...
		</profile>
```

- das HAuptprojekt bekommt einen Eintrag für DependencyManagement für Das Hauptprojekt selbst

```
<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>${project.groupId}</groupId>
				<artifactId>Hauptprojekt</artifactId>
				<version>${project.version}</version>
			</dependency>
		</dependencies>
	</dependencyManagement>
```
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:

```
<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???)
```


----------



## dermoritz (21. Dez 2011)

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?


----------



## kama (21. Dez 2011)

Hi

wie wäre es mit der folgenden Struktur:

```
module-web
    +--- pom.xml (packaging: pom) mit modules
    +--- module-war
              +--- pom.xml (parent: module-web)
    +--- module-it
              +--- pom.xml (parent: module-web)
```
Gruß
Karl Heinz Marbaise


----------



## dermoritz (21. Dez 2011)

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:

-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:

```
...

	<modules>
		<module>hauptP</module>
		<module>iTests</module>
	</modules>
	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>${project.groupId}</groupId>
				<artifactId>hauptP</artifactId>
				<version>0.0.1-SNAPSHOT</version>
			</dependency>
		</dependencies>
	</dependencyManagement>
...
```
Das Problem ist, dass "${hauptP.version}" nicht funktioniert! (Sollte es aber oder?)

test pom

```
<parent>
		<artifactId>mutti</artifactId>
		<groupId>${project.groupId}</groupId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<groupId>${project.groupId}</groupId>
	<artifactId>iTests</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>iTests</name>
	<dependencies>
		<dependency>
			<groupId>${project.groupId}</groupId>
			<artifactId>hauptP</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>
```

hauptP ist nicht so spannend - steht nur der parent ->mutti drinne

EDIT:

das mit der Version hat sich geklärt - geht einfach nicht. nun verwende ich project.version


----------



## kama (21. Dez 2011)

Hi,



dermoritz hat gesagt.:


> 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...



dermoritz hat gesagt.:


> -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....



dermoritz hat gesagt.:


> - Ein release müsste man dann immer mit dem parent machen oder? (wäre kein Problem)


Selbstverständlich....



dermoritz hat gesagt.:


> - Der ci Server würde einfach immer das parent bauen oder?


Ähm..der CI Server checkt das gesamte Projekt aus und baut eben vom Root des Projektes aus...


An dem ist ein Grundlegende Sache Falsch....


```
<modules>
		<module>hauptP</module>
		<module>iTests</module>
	</modules>
	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>${project.groupId}</groupId>
				<artifactId>hauptP</artifactId>
				<version>0.0.1-SNAPSHOT</version>
			</dependency>
		</dependencies>
	</dependencyManagement>
...
```
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!).

Ein Parent hat nur modules:

```
<modules>
		<module>hauptP</module>
		<module>iTests</module>
	</modules>
```
nichts anderes...

Ein Module z.B. das iTestS module benötigt dann das HauptP dann hat dass eine dependency...

iTest:

```
<dependencies>
  ...
  <dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>hauptP</artifactId>
    <version>${project.version}</version>
  </dependency>
</dependencies>
```

Gruß
Karl Heinz Marbaise


----------



## dermoritz (21. Dez 2011)

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 :-|)

*EDIT*

könnte das irgendwie helfen: Changing the project version ?


----------



## kama (21. Dez 2011)

Hi,



dermoritz hat gesagt.:


> 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...




dermoritz hat gesagt.:


> 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 behaupte jetzt mal dass das nicht sinnvoll wäre ...Das ganze macht als Multi-Module mehr sinn...



dermoritz hat gesagt.:


> Wodurch wird eigentlich project.version gesetzt? durch die parent-beziehung oder durch die modul-beziehung?


Durch die Parent Beziehung...



dermoritz hat gesagt.:


> (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)


man checkt das gesamte Projekt aus und macht auch auf dem gesamten Projekt update...und nicht auf einzelne Bereiche....das Führt zu Problemen....

Ich glaube wir müssen hier noch klären, was Du genau unter "parent" verstehst ? 


```
DeinProjekt
     +--- pom.xml (parent; packagin pom; modules)
     +--- module1
               +--- pom.xml (parent...)...
     +--- module2
               +--- pom.xml
     +--- module3
               +--- pom.xml
     +--- module4
```
Also hier immer das vollständige Projekt auschecken und damit arbeiten...




dermoritz hat gesagt.:


> - 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....



dermoritz hat gesagt.:


> könnte das irgendwie helfen: Changing the project version ?


Nein. Das ist im Falle eines Multi-Module builds nicht notwendig...die Versionsänderungen werden per Release gemacht...(mvn releaserepare ...)..

Gruß
Karl Heinz


----------



## dermoritz (21. Dez 2011)

Danke!

"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)


----------



## kama (21. Dez 2011)

Hi,



dermoritz hat gesagt.:


> 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...



dermoritz hat gesagt.:


> 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.


Genau so ist es...



dermoritz hat gesagt.:


> (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)


Haben die Entwickler kein Maven Training bekommen ? Wenn nicht Hm.......Abgesehen davon müssen die das Lernen....das ist Aufgabe eines Entwicklers...

Ich hoffe nicht dass Ihr nocht "m2eclipse" nutzt? "m2e" ist der Richtige Weg...

Gruß
Karl Heinz Marbaise


----------



## dermoritz (21. Dez 2011)

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 ;-)


----------



## dermoritz (21. Dez 2011)

Was mir gerade noch einfällt zu:

"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

```
<module>../einModul</module>
```

kommt man um das deployen des parents - nach jedem release - nicht herum oder? - maven findet das parent sonst nicht oder?


----------



## kama (21. Dez 2011)

Hi,



dermoritz hat gesagt.:


> ```
> <module>../einModul</module>
> ```


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...

Gruß
Karl Heinz Marbaise


----------



## dermoritz (21. Dez 2011)

Danke!

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"


----------



## kama (21. Dez 2011)

Hallo,



dermoritz hat gesagt.:


> Dort brauche ich ja nur das parent eintragen als Job?!


ja genau...



dermoritz hat gesagt.:


> 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....



dermoritz hat gesagt.:


> 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?


Mach mal ein Beispiel wie Du das genau meinst...damit wir nicht aneinander vorbei reden...



dermoritz hat gesagt.:


> Oder anders gefragt lohnt es sich die Struktur im SVN zu ändern, so dass sie den Konventionen (alle module unter parent) entspricht?


Hängt davon ab.......ich warte mal Dein Beispiel ab...

Gruß
Karl Heinz Marbaise


----------



## dermoritz (21. Dez 2011)

"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.


----------



## kama (22. Dez 2011)

Hallo,



dermoritz hat gesagt.:


> "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..)...




dermoritz hat gesagt.:


> 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?


Um das nochmal klarzustellen....
Struktur wie folgt:

```
DeinProjekt
     +--- pom.xml (parent; packagin pom; modules)
     +--- module1
               +--- pom.xml (parent...)...
     +--- module2
               +--- pom.xml
     +--- module3
               +--- pom.xml
     +--- module4
```
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)...



dermoritz hat gesagt.:


> 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)...

Gruß
Karl Heinz Marbaise


----------



## dermoritz (2. Jan 2012)

(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)


----------



## kama (2. Jan 2012)

Hi,

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...

....oder das hier auch: http://78.46.16.202:8080/jenkins/job/Maven-License-Verifier-Plugin-Site/ (mit Metriken)...
oder hier eben ein Maven Projekt mit Integrationstest per mvn clean verify (http://78.46.16.202:8080/jenkins/job/SupoSE-default/167/console)...

BTW: Deine Struktur sollte man and den "Standard" ranbringen...macht das leben einfacher...

Gruß
Karl Heinz Marbaise


----------



## dermoritz (2. Jan 2012)

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?


----------



## kama (2. Jan 2012)

Hi,

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...


```
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....


Gruß
Karl Heinz Marbaise


----------



## dermoritz (3. Jan 2012)

Danke KAMA,

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).

Hat jemand vielleicht Tips zum Weiterlesen?


----------



## kama (3. Jan 2012)

Hallo,



dermoritz hat gesagt.:


> 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?)


Kannst Du ...siehe hier. Wenn Du aber noch nicht so viele hast eventuell wirklich umbenennen....



dermoritz hat gesagt.:


> 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).



Server starten/beenden da wäre je nachdem mit was Du arbeitest cargo2 ein Blick wert...

Im Bereich DB-Umgebungen bzw. besser SQL (sql-maven-plugin; Für setup der DB etc.)..eventuell auch noch das dbupgrade plugin

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...

Gruß
Karl Heinz Marbaise


----------



## dermoritz (3. Jan 2012)

Vielen Dank ... bin dann mal lesen

Ü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.


----------

