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.
Maven, Cargo, Selenium - brauche Hilfe bei Konfiguration
(Ich schreib erstmal was ich will und weiter unten wie ich es umgesetzt hab)
Plan ist im Integrationstestmodul Seleniumtests zu machen. Und zwar so: Die Seleniumtests sollen alle im IT-Modul untergebracht sein. Die Seleniumtests sollen nicht im default Profil laufen sondern müssen explizit aktiviert werden. Cargo:run soll im Hauptmodul funktionieren (wenn der Container läuft sollten die Seleniumtests auch aus Eclipse heraus laufen oder?)
Bei Aktivierung der Seleniumtests soll cargo irgendwann nach "package" des Hauptmoduls starten und irgendwann nach "integration-test" des IT-Moduls stoppen.
Was wäre euer Vorschlag für diesen Use-Case?
Im Moment läuft es ich finde es aber sehr unschön:
- im parent ist cargos Minimalkonfiguration (tomcat7x, ports) in plugin-management eingetragen
- Im Hauptmodul wird in "pre-integration-test" (alles nach "package" ginge wahrscheinlich) cargo gestartet und die war-Datei deployed (in einigen Profilen wird ein andere war-Name gesetzt)
- im It- Modul wird der Test in "integration-test" ausgeführt (per fail-safe) und cargo wird in post-integration-test gestoppt (man muss cargo sagen wo der container ist - verweis auf das hauptmodul)
- das automatische starten und stoppen inklusive des "includes" der Seleniumtests (**/*Selenium.java) passiert in einem Profil mit Aktivierung "-DseleniumTest=true"
Warum ich es unschön finde (für die die es schön finden ): Die Konfiguration von Cargo ist nun in alle drei Module verteilt. Optimal wäre so eine übergreigfende Geschichte im parent untergebracht. Das Problem ist, dass z.B. die war-Namen im Hauptmodul geändert werden (im Profil ci und release):
Code:
<warName>${project.artifactId}</warName>
Kann ich aus dem parent auf properties der module zurückgreifen? (module1.project.artifactid) Oder kann ich allgemein auf porperties der module zurückgreifen?
Damit würde ich dann viel zentralisieren können. Oder denke ich einfach völlig falsch?
- Im Hauptmodul wird in "pre-integration-test" (alles nach "package" ginge wahrscheinlich) cargo gestartet und die war-Datei deployed (in einigen Profilen wird ein andere war-Name gesetzt)
- das automatische starten und stoppen inklusive des "includes" der Seleniumtests (**/*Selenium.java) passiert in einem Profil mit Aktivierung "-DseleniumTest=true"
Kann ich aus dem parent auf properties der module zurückgreifen? (module1.project.artifactid) Oder kann ich allgemein auf porperties der module zurückgreifen?
Damit würde ich dann viel zentralisieren können. Oder denke ich einfach völlig falsch?
"Warum benutzt du hier nicht einfach eine Profile ID ...mvn -Pselenium ? "
Das hab ich mich neulich auch gefragt. Hab es dann aber erstmal so gelassen (funktioniert ja). Wofür braucht man dann überhaupt noch Aktivierung durch Property?
"Warum legst Du nicht einfach die Konfiguration in den Plugin-Management Block..."
Das hab ich zum Teil schon gemacht (die Minmalkonfiguration). Aber für den Rest muss das parent-Modul eben bestimmte dinge der Kinder Wissen.
Wie zum Beipiel deren Ordner bzw. deren "${project.artifactId}"
"Warum wird denn der Name geändert ?...":
Damit im ci Profil ein Name unabhängig von der Version erzeugt wird. Das Artefakt "Hauptmodul.war" kann ich sehr einfach automatisch auf nen Server (re)deployen (Jenkins deploy plugin oder manuelles überschreiben). Falls für jede Version etwas deployed würde würde der Server zumüllen und die url ändert sich auch immer.
"Du kannst auf Properties des Parents zugreifen aber nicht von Kindern auf Properties von anderen Kindern..."
Kann ich per property im parent auch die Namen/artifactId's der Module setzen? oder kann ich vom parent direkt auf deren Namen zugreifen?
Eine entscheidende Frage bleibt aber: Kann ich das Starten (nach package vom Hauptmodul) und Stoppen (nach "integration-test" von IT-Modul) des Containers zentral steuern (im parent)? Denn über "plugin-management" wird ja noch kein plugin ausgeführt?!
Das hab ich mich neulich auch gefragt. Hab es dann aber erstmal so gelassen (funktioniert ja). Wofür braucht man dann überhaupt noch Aktivierung durch Property?
Das hab ich zum Teil schon gemacht (die Minmalkonfiguration). Aber für den Rest muss das parent-Modul eben bestimmte dinge der Kinder Wissen. Wie zum Beipiel deren Ordner bzw. deren "${project.artifactId}"
"Warum wird denn der Name geändert ?...":
Damit im ci Profil ein Name unabhängig von der Version erzeugt wird. Das Artefakt "Hauptmodul.war" kann ich sehr einfach automatisch auf nen Server (re)deployen (Jenkins deploy plugin oder manuelles überschreiben). Falls für jede Version etwas deployed würde würde der Server zumüllen und die url ändert sich auch immer.
Warum nutzt Du nicht einfach den context name ...damit bleibt die URL gleich..Ok.....aber wie oft hast Du andere Versionen ? Nutzt Du keine SNAPSHOT's . Die Version sollte sich doch erst nach einem Release ändern...Du könntest ja für das WAR-Module den FinalName überschreiben...?(Nicht schön...)..
Eine entscheidende Frage bleibt aber: Kann ich das Starten (nach package vom Hauptmodul) und Stoppen (nach "integration-test" von IT-Modul) des Containers zentral steuern (im parent)? Denn über "plugin-management" wird ja noch kein plugin ausgeführt?!
Zusammengefasst: Meine prinzipielle Konfiguration würde erstmal so bleiben:
- Grundkonfiguration im parent via Pluginmanagement.
- start/stop von cargo in den Untermodulen
- Aktivierung per Property oder Profile - is eigentlich egal (ich werde es trotzdem ändern wie du vorgeschlagen hast - find ich inzwischen auch hübscher)
Nun zu dem Detail der War-Benennung. Ziel ist auf einem "Staging server" immer den aktuellen Snapshot zu haben, unter einer festen url unabhängig zur Version. Bei jedem Release wird unabhängig davon eine war mit version deployed.
Im Moment regele ich das mit
Code:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<!-- no version attached to name -->
<warName>${project.artifactId}</warName>
</configuration>
</plugin>
Wenn in diesem Profil cargo starten soll muss cargo entsprechend angepasst werden:
Code:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<configuration>
<deployables>
<deployable>
<!-- in ci profile the final name is changed, set it accordingly-->
<location>${project.build.directory}\${project.artifactId}.${project.packaging}</location>
</deployable>
</deployables>
</configuration>
</configuration>
</plugin>
Ich bin allen Vorschlägen gegenüber offen, die das etwas schöner machen. (final name? context name? - wie sehe das dann aus?)
Da das Starten und Stoppen ja nicht zentral im parent gelagert werden kann, muss das hier auch nicht mehr in die parent-pom.
): Die Konfiguration von Cargo ist nun in alle drei Module verteilt. Optimal wäre so eine übergreigfende Geschichte im parent untergebracht. Das Problem ist, dass z.B. die war-Namen im Hauptmodul geändert werden (im Profil ci und release):
