custom:produzione_war_da_progetto_template_custom [GeowebFramework]

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
===== Creazione di un progetto da template, customizzazione e produzione dei WAR =====
Utilizzando questa procedura, è possibile creare autonomamente i file WAR di cui si ha necessità partendo da un template già esistente su Artifactory. 

E' vivamente consigliato, anche se non mandatorio, che tale procedura venga attuata nelle folder appositamente predisposte nella versione locale del //Repository di Commessa//, [[custom:repo_git_di_commessa|descritto qui]].

Prima di procedere, ci si deve assicurare di aver installato nel proprio pc sia Apache Maven ([[gwinstguide:idxinstguide:installazione_maven|Installazione di Maven]]) sia Git ([[gwinstguide:idxinstguide:installazione_git|Installazione di Git]]).



==== Passaggio 1: Generazione della folder del progetto maven (esecuzione del file makeproj*.bat) ====

=== Procedura ===
La prima cosa da fare per creare un progetto di base nel proprio pc cliccare sul seguente link e avviare il download della cartella ZIP, in base alla versione major del progetto da generare:
  * {{ :custom:makegproj-4.6.x-release.zip |}}
  * {{ :custom:makegproj-4.6.x.zip | makegproj-4.6.x.zip (PRE-RELEASE, @Deprecated)}}
  * {{ :custom:makegproj-4.5.x.zip |}}
  * {{ :custom:makegproj.zip |}} (per le versioni precedenti alla 4.5.X)
Dopo aver decompresso makegproj-4.6.x.zip, salvare il file makegproj-4.6.x.bat nella cartella del repository di prodotto/commessa.
Step:
  * doppio click su makegproj-X.bat
  * inserire il nome del nuovo progetto maven da generare. Es: **mvn_project_name**
  * inserire  la versione di GeowebFramework, scelta tra quelle disponibili su Artifactory. Es: 
    * **4.6.0**
    * **4.6.0-SNAPSHOT**
    * **4.5.4**
    * **4.4.19**
    * **4.4.19-HOTFIX**

La finestra di //shell// mostrerà l'avanzamento del download. {{ :custom:shell_makeproj.png?400 |}}

Alla fine del processo, la finestra si chiuderà automaticamente e si avrà una cartella con il nome del progetto (cioè quello inserito precedentemente in makeproj.bat) che conterrà tutti i file di configurazione con setting di base.

Il file makegproj*.bat, quindi, è utilizzato **una tantum**, cioè solo nella fase iniziale della creazione del nuovo progetto.


==== Passaggio 2: Personalizzazione dei file di configurazione ====

La prima operazione da fare è intervenire sul file **pom.xml**:
  * verificare la **<com.geowebframework.version>** di GeowebFramework (che deve coincidere con quella usata nel makegproj.bat)
  * dichiarare le **<dependency>** da utilizzare, comprensive di versionamento:
<code xml><dependency>
	<groupId>com.geowebframework</groupId>
	<artifactId>ispplugin</artifactId>
	<version>1.0.0</version>
</dependency></code>

In aggiunta, devono essere eventualmente modificati anche alcuni file di configurazione. In particolare, nel percorso //[nome_progetto]\src\main\resources\// ci sono:
  * Il file **configuration.properties**, che raccoglie tutti i dati configurabili del progetto, che rappresentano entità costanti, come ad esempio i dati di accesso al database; anche in questo caso, ogni parametro è memorizzato come una coppia di stringhe, una contiene il nome del parametro (cioè la chiave) e l'altra memorizza il valore.
  * Il file **log4j2.properties** (**log4j.properties**, pre 4.6.x), che contiene tutte le informazioni (codificate come coppie chiave-valore) necessarie alla scrittura dei log di Maven. Il log, infatti, è uno strumento molto utile che va configurato nel modo corretto: esso raccoglie gli output dei diversi processi e, analizzando questi output, permette di capire cosa è accaduto in caso di errori.
  * Il file **remapConfiguration.properties** che ha lo scopo di mappare i nomi delle proprietà all'interno del **configuration.properties** con nomi di variabili d'ambiente o di sistema.
  * Il file **webconfig.ini** che serve per alcune configurazioni della piattaforma Mapguide.
Invece, nel percorso //[nome_progetto]\src\main\webapp\WEB-INF\// si trovano: 
  * Il **dispatcher-servlet.xml**, che serve da controller per le applicazioni web basate su Spring. Il contenuto è standard, ma, in particolari ambienti, alcuni tag non vengono usati e devono essere cambiati.
  * Il file **web.xml**, che descrive l'esecuzione dell'applicazione web e contiene configurazioni per l'accesso ai database. Utile per configurare quale spring-security.xml utilizzare
  * Infine, il file **spring-security.xml**, che raccoglie informazioni di autenticazione e di connessione al metadata-source.
 
Le modifiche apportate ai vari file dipendono dal progetto, ma anche dall'ambiente in cui il progetto deve essere utilizzato.

=== Note war versioni 4.6.x-release ===

Sono provvisti nel modello 3 file spring-security.xml
  - **spring-security.xml** (senza keycloak, da arricchire con eventuale configurazione Identity Provider del cliente)
  - **spring-security-keycloak.xml** (specifico per keycloak)
  - **spring-security-deprecated.xml** (senza keycloak, con vari meccanismi di autenticazione usati in passato, anche @Deprecated)

Di default è utilizzato lo //spring-security-keycloak.xml//
Questa configurazione può essere modificata nel file **web.xml**

<code xml>
<!-- Spring Security STARTS -->
<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>
		<!-- TODO CONFIGURE, choose one between: -->
		<!-- /WEB-INF/spring-security.xml -->
		<!-- /WEB-INF/spring-security-keycloak.xml -->
		/WEB-INF/spring-security-keycloak.xml
	</param-value>
</context-param>
</code>

Lasciare solo lo spring-security*.xml di interesse, eliminando gli altri, e verificare la coerenza nel web.xml


Nel **pom.xml** sono commentati tutti i plugin disponibili allo stato attuale nel repository del framework.
Come sempre, decommentare i necessari moduli ed eliminare gli altri.
Aggiungere inoltre le dipendenze di eventuali repository di prodotto o di commessa.


=== Note war versioni 4.5.x ===

Le versione 4.5.0-SNAPSHOT era, secondo corrette politiche aziendali, destinata solo allo sviluppo. Logiche di commessa hanno portato di fatto all'utilizzo di questa versione.
Il dispiegamento sui clienti ha forzato anche il relativo versionamento: 4.5.1, 4.5.2, etc..
Per le versioni 4.5.X **non è stato prodotto uno specifico makegproj.bat**.
In attesa di uno specifico, la prassi da seguire è utilizzare il **makegproj.bat** precedente, avendo cura di modificare lo spring-security.xml in alcune parti

dentro il tag
<code xml>
<http auto-config="true" use-expressions="true" disable-url-rewriting="true">
...
</http>
</code>
va aggiunta la parte:
<code xml>
<intercept-url pattern="/resources/#{ T(com.geowebframework.metadataservice.registry.GwReleaseInfos).getRevision() }/fontawesome/**" access="permitAll" /> <!--issue #509-->
<intercept-url pattern="/resources/#{ T(com.geowebframework.metadataservice.registry.GwReleaseInfos).getRevision() }/images/favicon.png" access="permitAll" />
<intercept-url pattern="/resources/#{ T(com.geowebframework.metadataservice.registry.GwReleaseInfos).getRevision() }/images/${images.login.form.logo:gw4_enterprise.png}" access="permitAll" />
<intercept-url pattern="/resources/#{ T(com.geowebframework.metadataservice.registry.GwReleaseInfos).getRevision() }/${images.IndexBackground:IndexBackground.jpg}" access="permitAll" />	
</code>
immediatamente sotto la parte:
<code xml>
<intercept-url pattern="/resources/#{ T(com.geowebframework.metadataservice.registry.GwReleaseInfos).getRevision() }/icons/**" access="permitAll" />
</code>

Senza il fix potrebbe comparire navigando la schermata:

{{:custom:error_missing_font_awesome_in_spring-security.png}}



==== Passaggio 3: produzione del WAR ====

Terminate tutte le operazioni di configurazione e personalizzazione del progetto maven, bisogna assicurarsi di avere sotto la cartella dell'ambiente specifico, a seconda dell'OS, uno dei seguenti file:
  * makegwar.bat (Window)
  * makegwar.sh (Linux)
 E' possibile fare il download della seguente cartella compressa, che li contiene entrambi: {{ :custom:makegwar.zip |}}

Doppio click per eseguire il file. Si aprirà una finestra di //shell// che mostrerà l'avanzamento dell'operazione. Al termine della procedura, nella finestra verrà riportato un messaggio di successo se tutto è andato a buon fine, oppure un messaggio di errore in caso di eventuali problemi.
Il file WAR viene automaticamente salvato all'interno si **mvn_project_name/target**. 


---------------------------------

==== Creazione Webadmin war ====
**(Dalla versione 4.6.12)**
[[https://gitlab.com/geowebframework/geowebframework/-/issues/1257|issue #1257]]

=== Premessa ===
L'eccessivo ingombro degli artefatti webadmin (circa 250MB), che andavano a finire su Artifactory ad ogni tag, combinato al contestuale cambiamento delle policy di rilascio che ha previsto un tag esclusivo per ogni fix (sulla quarta cifra di versionamento 4.6.x.y), ha spinto per la trasformazione del modulo maven gw-webadmin in jar, in maniera che potesse essere inglobato in un pom.xml generico per la creazione del war.

Considerando anche gli effetti della [[https://gitlab.com/geowebframework/geowebframework/-/issues/1256|issue #1256]], i peso dell'artifact gw-webadmin è passato da 250MB a meno di 2MB su Artifactory

=== Procedura ===
Analogamente alla metodologia di produzione del war del webclient, è disponibile un template specifico da cui partire (valido per 4.6.* e 4.7.*)

  * {{ :custom:makewebadmin-4.6.x.zip |}}

Vanno eseguiti passaggi del tutto simili alla produzione dei war webclient.

=== Note ===
In generale non ci sarà mai bisogno di aggiungere maven dependency al pom.xml.

Le dipendenze che erano supportate precedentemente continuano ad esserlo
Widget e servizi interni al progetto geowebframework di:
  - gw-advanced
  - gw-cms
  - gw-approvals
  - gw-mnemonic-code
  - gw-3d-visualizer
  - gw-workflow
  
Widget e servizi esterni al progetto geowebframework
  - gw-tree-collection (2.1.3)

Widget e servizi deprecati:
  - postevita
  - gw-smartplatform

Se necessario ulteriori plugin di commessa/progetto che coinvolgano widget/tipi di menu possono essere sviluppati con la medesima modalità.
L'unica accortezza, nell'eventuale aggiunta della relativa dependency al pom.xml del webadmin, **e solo se questa abbia come propria dependency webclient**,  è quella di aggiungere solo le class:
  - pojo dei widget
  - pojo modello dati
  - XInitializerService.class che registra widget, tipi di menu e tipi di schede

Questo dovrebbe essere fatto in una delle modalità consentite da maven, da adattare in base al caso specifico.