Warum wird beim Hinzufügen eines Test Jars dieses Maven-Build zum Absturz gebracht?

Question

Also, ich werde langsam etwas genervt von Maven 2. Das Projekt-Setup, das wir haben, ist einfach: Ein "Kern" -Projekt, von dem sowohl ein "Batch" als auch ein "Web" -Projekt abhängen, sowie ein "Ear" -Projekt, das von "Web" abhängt. Ziemlich einfache Sachen.

Nun, da der Kern ziemlich häufig verwendet wird und dies das erste Mal ist, dass die Gruppe tatsächlich TDD (testgetriebene Entwicklung) durchführt, wurden ziemlich viele Mocks erstellt, hauptsächlich im Web-Projekt - das Batch-Projekt ist im Moment ziemlich einfach.

Das aktuelle (verschleierte) XML ist im Web-Pom enthalten, um das Kernprojekt als Abhängigkeit einzuschließen:

${project.groupId}
XYZ-core
${project.version}

Das Pom funktioniert, wenn nur dies enthalten ist, sowie der Rest der Jar-Dateien eingeschlossen ist. Eine der eingeschlossenen Jar-Dateien ist die Servlet-API, Version 2.4:

javax.servlet
servlet-api
${version.servlet-api}
provided

Dies ist als bereitgestellter Anwendungsbereich festgelegt, da es vom Web-Container bereitgestellt wird. Keine Überraschungen hier. Mit nur dem im Web-Pom enthaltenen Code werden die Tests ausgeführt und ohne Probleme installiert.

Aber jetzt gibt es all diese Mocks im Web. Batch kann auch einige dieser Mocks verwenden. Natürlich möchte ich daher die Kern Tests als Testbereich sowohl in Batch als auch im Web platzieren, damit ich die Mocks (die Kernfunktionalität nachahmen) in den Tests des Kerns platzieren kann, damit sie unter den Projekten gemeinsam genutzt werden können. Der folgende (verschleierte) Ausschnitt funktioniert im Batch-Projekt:

${project.groupId}
XYZ-core
tests
${project.version}
test

Wenn ich dies jedoch zum Web-Pom hinzufüge, erhalte ich das Ganze, wenn ich versuche, das Web zu erstellen.

XYZ.java:[33,16] kann Symbol nicht auflösen: Symbol: class HttpServletRequest

Wenn es entfernt wird, wird das Web erfolgreich erstellt.

Irgendwelche Ideen? Die Maven-Version ist 2.0.4. Ich könnte ein Upgrade versuchen, aber das würde viel Ärger bedeuten.

BEARBEITEN: Die Hauptklassen des Webs können nicht mit diesem Fehler kompiliert werden (auch HttpServletResponse wird nicht gefunden). Selbst wenn Tests übersprungen werden (-Dmaven.test.skip=true), tritt dieser Fehler auf.

Answer 1

Maven 2.0.4 ist drei Jahre alt und stammt aus einer Zeit vor einer ziemlich kritischen Änderung darin, wie Maven 2 mit Plugin-Versionen interagiert. Vor Maven 2.0.9 würde ein Maven-Build die neueste Version aller benötigten Plugins herunterladen. Es ist wahrscheinlich, dass Sie auf eine Inkonsistenz stoßen, weil Sie ein neueres Plugin mit Maven 2.0.4 verwenden. Bevor Sie etwas unternehmen, aktualisieren Sie auf alles über Maven 2.0.9, trotz des Aufwands. Ich bin überrascht, dass Sie noch mit 2.0.4 bauen können.

Zu diesem Zeitpunkt sollten Sie in Erwägung ziehen, entweder auf 2.0.10 oder 2.1.0 zu aktualisieren. Der Hauptunterschied besteht darin, dass 2.1.0 einige Parallel-Download-Verbesserungen und Unterstützung für verschlüsselte Serverpasswörter enthält.

Answer 2

Sie sollten mvn help:effective-pom mit und ohne den fehlerhaften Abschnitt überprüfen.

Sie könnten auch von diesem Fehler betroffen sein, aber Sie müssen überprüfen, ob er auf Ihre Situation zutrifft.

In jedem Fall sollten Sie es zumindest in einem temporären Bereich mit Maven 2.0.9 ausprobieren ... Sie können die Maven-Startskripte bearbeiten, damit Ihr bestehendes Repository nicht beeinträchtigt wird, usw. Nur so können Sie sicher sein, dass Sie nicht von einem bereits gelösten Fehler betroffen sind.

Answer 3

Dies ist kein Problem mit Ihrer Maven-Distribution selbst.

Im Allgemeinen verwenden Sie mvn dependency:tree, wenn Sie versuchen herauszufinden, warum bestimmte Abhängigkeiten nicht in ihren erwarteten Artefakten oder Scopes enthalten sind.

In Ihrem Fall benötigen Sie, obwohl Sie das Servlet-API-Artefakt als bereitgestellte Abhängigkeit haben, tatsächlich eine Implementierung, die während der Testphase verfügbar ist. Es scheint mir, als ob die Tests, die Sie im Batch ausführen, niemals Ihre Mock-Klassen importieren, die etwas aus javax.servlet importieren, aber Ihre Tests im Web importieren Mocks, die etwas aus javax.servlet importieren - korrigieren Sie mich, wenn ich mich da irre.

Ich würde vorschlagen, einige Jetty-Implementierungen als Abhängigkeit mit Tests Scope hinzuzufügen und zu sehen, ob Sie damit weiterkommen.