Ist es möglich, die Datei context.xml von Tomcat6 über das Maven Cargo Plugin zu liefern?

Question

Ich möchte die Datei context.xml von Tomcat wenn möglich aus dem META-INF-Verzeichnis meiner WAR-Datei entfernen. Kann dies mit Mavens Cargo Plugin geschehen? Ich kann nicht die richtige Konfiguration finden.

Answer 1

Eureka! Nach vielen Tagen des Studiums dieses Problems fand ich schließlich eine sehr effektive Lösung. Der Schlüssel besteht darin, Ihre Tomcat-XML-Kontextfragmentdatei zu verwenden und das <configfiles> Frachtelement zu verwenden, um es in das Verzeichnis conf/Catalina/localhost mit dem Namen context.xml.default zu löschen. Der einzige Nachteil ist, dass dies Ihre Kontextdefinitionen für alle Web-Apps verfügbar macht, aber das sollte nicht wirklich wichtig sein. Cargo verwendet diese Tomcat-Instanz, daher gibt es keine andere Web-App.

Hier ist die Konfiguration:

<configuration> <!-- Deployer configuration --> 
    <type>standalone</type> 
    <properties> 
     <cargo.servlet.port>${tomcat6.port}</cargo.servlet.port> 
    </properties> 
    <deployables> 
     <deployable> 
     <groupId>com.myapp<groupId> 
     <artifactId>myapp-war</artifactId> 
     <type>war</type> 
     <properties> 
       <context>${tomcat6.context}</context> 
     </properties> 
     </deployable> 
    </deployables> 
    <configfiles> 
     <configfile> 
     <file>${basedir}/../config/tomcat-context.xml</file> 
     <todir>conf/Catalina/localhost/</todir> 
     <tofile>context.xml.default</tofile> 
     </configfile> 
    </configfiles> 
</configuration> 

Das Nettoergebnis ist nicht mehr gefälschte WAR-Module für nur testen und nicht mehr Zusammenführung von WARs. Hoffe das hilft jemandem.

Answer 2

Ich habe noch keinen Weg gefunden, dies zu tun, aber ich habe eine Arbeit gefunden, die in meinem Projekt funktioniert. Ich habe derzeit ein Projekt mit im Wesentlichen drei Submodule:

dependencies 
    webapp 
    smoketest 

Als ich das „Webapp“ Projekt baute, führe ich die folgende Plugin-Deklaration:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-war-plugin</artifactId> 
    <executions> 
     <execution> 
     <id>create-war-smoketest</id> 
     <phase>verify</phase> 
     <goals> 
      <goal>war</goal> 
     </goals> 
     <configuration> 
      <webappDirectory>${project.build.directory}/exploded</webappDirectory> 
      <primaryArtifact>false</primaryArtifact> 
      <classifier>smoketest</classifier> 
      <webResources> 
      <resource> 
       <filtering>true</filtering> 
       <directory>src/test/resources/smoketest</directory> 
       <targetPath>META-INF</targetPath> 
       <includes> 
        <include>context.xml</include> 
       </includes> 
      </resource> 
      </webResources> 
     </configuration> 
     </execution> 
    </executions> 
</plugin> 

Und dann, wenn ich bin mit meiner Cargo/WebTest Suite im Projekt Smoketest, gebe ich das WAR-Datei Smoketest als Abhängigkeit und in meiner Frachtkonfiguration eingestellt meine deployrables thusly:

<deployables> 
    <deployable> 
     <groupId>${pom.groupId}</groupId> 
     <artifactId>webapp</artifactId> 
     <type>war</type> 
     <properties> 
      <context>smoketest</context> 
     </properties> 
    </deployable> 
</deployables> 

Mit der Abhängigkeit l ooking so etwas wie:

<dependencies> 
    <dependency> 
     <groupId>${pom.groupId}</groupId> 
     <artifactId>webapp</artifactId> 
     <version>${pom.version}</version> 
     <classifier>smoketest</classifier> 
     <type>war</type> 
     <scope>system</scope> 
     <!-- trick the dependency plugin to never look for it in the repo --> 
     <systemPath>${basedir}/../webapp/target/webapp-${pom.version}-smoketest.war</systemPath> 
    </dependency> 
</dependencies> 

Es ist extrem dreckig, aber es funktioniert zumindest ... für jetzt. Eine kurze Anmerkung: Mein Kommentar darüber, es zu zwingen, nie nach einer Version im Repo zu suchen, ist möglicherweise zu diesem Zeitpunkt falsch; Ich denke, dass dieser Trick durch eine Änderung des Abhängigkeits-Plugins irgendwann kaputt gegangen sein könnte.