Il filtro delle risorse Web con il plugin di guerra Maven non funziona in Eclipse con m2e

Question

Sto provando a filtrare un file di configurazione Spring usando il filtro Maven. Il mio POM è configurato in questo modo:

 ... 
     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-war-plugin</artifactId> 
      <version>2.2</version> 
      <configuration> 
      <webResources> 
       <resource> 
       <filtering>true</filtering> 
       <targetPath>WEB-INF/context</targetPath> 
       <directory>src/main/webapp/WEB-INF/context</directory> 
       <includes> 
        <include>applicationContext.xml</include> 
       </includes> 
       </resource> 
      </webResources> 
      </configuration> 
     </plugin> 
     ... 

e

<profiles> 
    <profile> 
     <id>desarrollo</id> 
     <activation> 
      <activeByDefault>true</activeByDefault> 
     </activation> 
     <build> 
      <filters> 
       <filter>src/main/properties/dev.properties</filter> 
      </filters> 
     </build> 
    </profile> 
    <profile> 
     <id>pruebas</id> 
     <build> 
      <filters> 
       <filter>src/main/properties/test.properties</filter> 
      </filters> 
     </build> 
    </profile> 
      ... 

Funziona benissimo quando si richiama direttamente Maven.

Sfortunatamente, quando si distribuisce a caldo la webapp in Tomcat 6 con Eclipse WTP e m2e, viene sempre scelta la versione non filtrata di applicationContext.xml. (Il file applicationContext.xml nella cartella target/m2e-wtp/web-resources/WEB-INF/contesto non viene mai filtrato)

Non riesco a trovare alcuna documentazione utile sull'argomento. Non sono nemmeno sicuro che sia implementato in m2e.

C'è qualcosa di sbagliato nella mia configurazione o questa è una funzione non implementata?

Answer 1

Bene, finalmente ho capito.

Prima di tutto, ho fatto ciò che ha sottolineato il khmarbaise. Ho spostato applicationContext.xml nella cartella delle risorse. Il plug-in di guerra webResources è pensato per funzionare con risorse esterne e il filtraggio di un file nella stessa cartella di destinazione non è la migliore pratica. Ho aggiornato il POM per riflettere la nuova configurazione

<resources> 
     <resource> 
      <directory>src/main/resources</directory> 
      <filtering>true</filtering> 
     </resource> 
    </resources> 

e

 <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-war-plugin</artifactId> 
      <version>2.2</version> 
      <configuration> 
       <webResources> 
        <resource> 
         <filtering>true</filtering> 
         <targetPath>WEB-INF/context</targetPath> 
         <directory>src/main/resources/WEB-INF/context</directory> 
         <includes> 
          <include>applicationContext.xml</include> 
         </includes> 
        </resource> 
       </webResources> 
      </configuration> 
     </plugin> 

Così, la metà del credito per lui. Ma non era abbastanza, non funzionava ancora. Mi sono reso conto che Maven/m2e stava effettivamente filtrando il mio file, ma non ha ottenuto i miei file delle proprietà definite. Dopo alcuni test ho scoperto che m2e sta ignorando l'opzionenella sezione di attivazione dei profili.

Così, ho aggiunto il mio profilo di default per la configurazione di progetto Maven e poi ha funzionato

Answer 2

Si è tentato di mettere le risorse in src/main/resources/WEB-INF/... anziché e configurato l'area delle risorse su filter the resources invece di mettere la configurazione in una posizione non predefinita.

Answer 3

Ho avuto un problema simile con il filtraggio web.xml. Ho risolto il problema reimportando l'intero progetto in eclissi.

Il motivo era un file corrotto /.settings/org.eclipse.wst.common.component. In questo file viene definito l'ordine dei file copiati nella directory di distribuzione dei server Web locali. Per esempio:

<?xml version="1.0" encoding="UTF-8"?><project-modules id="moduleCoreId" project-version="1.5.0"> 
    <wb-module deploy-name="liquidvote-rest"> 
    <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/> 
    <wb-resource deploy-path="/" source-path="/src/main/webapp" tag="defaultRootSource"/> 
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/> 
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/> 
    <property name="context-root" value="myapp"/> 
    <property name="java-output-path" value="/myapp/target/classes"/> 
    </wb-module> 
</project-modules> 

Se il web.xml o application.xml esiste in diverse directory sarà preso dalla prima directory trovata. Pertanto è importante che

<wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/> 

è la prima voce.

Troverete ulteriori informazioni allo http://wiki.eclipse.org/M2E-WTP_FAQ nella sezione "Che cos'è questa cartella delle risorse Web?"

Answer 4

Ho appena avuto un problema simile. La mia soluzione non è elegante e non ne sono orgoglioso, ma diciamo che è accettabile. Nel mio caso ho un'applicazione mvc boot spring con applicazione swagger (per i tester testare la nostra API). Il fatto è che stiamo usando questa app in due ambienti, quindi ho creato due profili: dev e test. In dev env vorremmo avviare l'applicazione da eclipse con "run as" in modo che il percorso di contesto sia vuoto (so che può essere impostato in primavera java config, ma non è l'unico segnaposto che vorremmo cambiare) e in test env l'applicazione viene eseguita nella nostra versione personalizzata di tomcat ... quindi il percorso di contesto è lo stesso del nome del file di guerra.

ed ecco il problema: lo swagger chiama i documenti di riposo su questo percorso di contesto e dipende dal profilo della molla. Quindi abbiamo una risorsa web che deve essere filtrata. All'inizio ho provato ad utilizzare il filtro M2E-WTP:

... 
<build> 
<plugins> 
<plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-war-plugin</artifactId> 
       <configuration> 
        <webResources> 
         <resource> 
          <filtering>true</filtering> 
          <directory>src/main/webapp</directory> 
          <includes> 
           <include>**/scripts.js</include> 
          </includes> 
         </resource> 
        </webResources> 
       </configuration> 
      </plugin> 
... 

era funzionante ma eseguito solo in incorporato in tomcat eclisse o dalla linea di comando java -jar non funzionava con "run come" da Eclipse.

La risorsa è stata filtrata e li ho visti in risorse Web nella destinazione, ma eclissi sembra essere in esecuzione direttamente su un codice sorgente o sta facendo una copia che non conosco ... non può vedere le risorse filtrate ... così ho pensato che farò qualcosa di simile:

<resources> 
      <resource> 
       <directory>src/main/resources</directory> 
      </resource> 
      <resource> 
       <filtering>true</filtering> 
       <directory>src/main/resources/webapp/swagger</directory> 
       <targetPath>${basedir}/src/main/webapp/swagger</targetPath> 
       <includes> 
        <include>scripts.js</include> 
       </includes> 
      </resource> 
     </resources> 

non è la soluzione più fortunato, perché è modifing il codice e non il bersaglio, ma almeno si sta lavorando. Se qualcuno avesse qualche suggerimento su come farlo funzionare senza modifiche al codice sarei grato.

Answer 5

Ho provato tutto quanto descritto sopra senza successo. I file sono stati filtrati e generati correttamente nella cartella "m2e-wtp", ma per qualche ragione Eclipse stava copiando file da "target/classi".

Così, ho cambiato il mio pom.xml, cambiando la cartella di destinazione da "m2e-wtp" a "target/classes", come il code ahead.

Importante: ogni volta che è necessario eseguire una creazione di esperti sul progetto, è necessario modificare il pom per creare il progetto.

Answer 6

Oggi ho avuto un problema simile quando diversi vasi erano inclusi in guerra. Ho impostato il filtro e ho confrontato i vasi originali con i filtri. Sembrano essere uguali, ma questo non è vero. Ho provato a rinominare jar in zip e non sono stato in grado di decomprimere il contenuto a causa della struttura corrotta all'interno di jar (zip) mentre quella originale era ok. Viene anche menzionato qui adding filtering web resources dove si dice che il filtro deve essere impostato su false per evitare di corrompere i file binari.